Cloud-based federated identity for the Internet of Things

Cloud-based federated identity for the Internet of Things The Internet of Things (IoT) has significant security and privacy risks. Recent attacks have shown that not only are many IoT devices at risk of exploit, but those devices can be successfully used to attack wider systems and cause economic damage. Currently, most devices connect to a cloud service that is provided by the manufacturer of the device, offering no choice to move to more secure systems. We outline a proposed model for IoT that allows the identity of users and devices to be federated. Users and devices are issued with secure, random, anonymised identities that are not shared with third parties. We demonstrate how devices can be connected to third-party applications without inherently de-anonymising them. Sensor data and actuator commands are federated through APIs to cloud services. All access to device data and commands is based on explicit consent from users. Each user’s data is handled by a personal cloud instance providing improved security and isolation, as well as providing a trusted intermediary for both devices and cloud services. We demonstrate this model is workable with a prototype system that implements the major features of the model. We present experiment results including performance, energy usage, capacity and cost metrics from the prototype. We compare this work with other related work and outline areas for discussion and future work. Keywords Cloud computing · Distributed authentication and authorisation · Federated identity management · IoT 1 Introduction The result is that users are reliant on particular CSPs. These may be hacked, or may go out of business rendering Internet of Things (IoT) devices are proliferating throughout devices inoperable. A common attack on CSPs has been to the world, bringing with them a significant threat to privacy steal credentials and publish users’ passwords. Hacked devices not only can be used to steal personal and security. There are multiple concerns with IoT devices. One of the key issues in the IoT space is the concern that data but also can be used to launch attacks on other when a device is purchased, it is tied to a specific web systems. In late 2016, large parts of the US East Coast system or cloud service, which is owned and managed by a Internet were disabled by a distributed denial of service cloud service provider (CSP). attack (DDoS), launched from a botnet running across In traditional Internet systems, users can migrate away approximately 100,000 IoT devices including IP-enabled from insecure services, because of interoperability and CCTV cameras [1]. choice. For example, the instant messaging market has seen In addition, there are other security and privacy con- the emergence of a number of more secure systems, includ- cerns. Small, inexpensive and/or low-power devices do not ing WhatsApp, Signal and Threema. In the IoT, the devices properly support encryption allowing communications to are often hard-coded to work with only specific Inter- be stolen. Few devices use well-defined identity models, meaning that spoofing attacks are possible. Data may be net systems, using private protocols and specific servers. validly shared by multiple cloud services but then aggre- gated to de-anonymise user information and infringe on Paul Fremantle privacy. We have previously identified a number of secu- paul.fremantle@port.ac.uk rity and privacy concerns with IoT which are documented Benjamin Aziz in [2]. benjamin.aziz@port.ac.uk We outline a new model, together with a prototype and 1 experimental results that aims to address these issues. We School of Computing, University of Portsmouth, call this model OAuthing. Portsmouth, UK 416 Ann. Telecommun. (2018) 73:415–427 1.1 Aims and objectives to cover a significant portion of this space, we have chosen to restrict the effort to cover: Based on the privacy and security concerns identified above, – Devices with a direct TCP/IP connection to the Internet the following research questions were identified: – Devices that can be owned or managed by a single – RQ1: Is there a model and architecture for IoT that person effectively federates identity and consent management? – Systems where the privacy of the data is relevant to the – RQ2: Can we provide pseudonymous access to IoT owner of a device. systems such that identity is not implicitly shared even For example, this work does not yet address devices in secure flows? where the device connects via bridging through an app on a – RQ3: Does this approach provide improved privacy and mobile phone or via a device gateway. However, the app on security for IoT networks? the phone or the local gateway could be secured using this – RQ4: Can this approach be implemented without model. adding an infeasible burden to the performance, cost and energy usage of an IoT network? 1.4 Outline of the paper The aim of this work is to answer these four research questions. The remainder of this paper continues with the following organisation. In Section 2, we propose a model of the 1.2 Contributions different parties involved and an architecture that supports decoupling of different actors in the environment. In The contributions of this work in addressing these issues Section 3, we outline a prototype middleware system that we include the following: have created to implement this model, alongside prototype devices and cloud services that demonstrate end-to-end – An architecture and system model that allows the flows. In Section 4, we outline the experimental results, federation of multiple parties: the manufacturer, the together with the test harness that was built to gather identity provider, the device identity management, and data. We discuss the related work and compare it to our cloud services and applications that require access to results in Section 5. In Section 6, we analyse the outcomes IoT data. This federation and decoupling encourages of the experimental results and the overall model. We choice of provider as well as reducing the data available also outline a set of further work identified during this in any given attack. research. – Clearly defined device and user registration processes, based on the OAuth2 protocol, that have been extended to support IoT devices and be effective in device 2Model scenarios. – A model for providing anonymous identities for users, In the following section, we outline a model—called reducing the chance that leaked data can be tied to OAuthing—that aims to federate identity and consent users. management for IoT systems. We utilise the UML2 [3] – An architecture that provides each user with a separate graphical modelling notation to model the participants and cloud instance to handle sharing device data, and an flows of this approach. approach for dynamically provisioning these cloud instances. 2.1 Participants – A demonstration of the workability of the model through the creation of a working prototype, together Figure 1 shows the current situation for many IoT systems, with a test harness. where there is no federation and the device talks to a single – Experimental results on the including energy usage, service that manages identity, stores data, provides a user performance, cost and capacity metrics of the prototype. web interface etc. By comparison, the federated model we present in 1.3 Assumptions and scope Fig. 2 allows different federated parties to provide different services that work together. The Internet of Things encompasses a vast array of The participants of the OAuthing model are as follows: environments, from small devices that connect over low- power protocols like Bluetooth LE, to industrial monitoring – The user identity provider (UIdP): this is an existing devices. While we believe that this work could be extended login system where users present their credentials Ann. Telecommun. (2018) 73:415–427 417 We utilise a cloud environment to dynamically launch PCM instances on behalf of users as needed. – Intelligent gateway (IG): the IG interfaces with the DIdP to validate identities and access authorisation policies and to the cloud infrastructure to instantiate new PCMs. Devices and CSs connect to the IG, and it routes requests to each user’s PCM. – Third-party application (TPA): a device is an IoT device if and only if it shares or receives data and commands with an Internet service. Users control which TPAs can access their sensor data or control Fig. 1 Existing approach for IoT device cloud their actuators by explicitly consenting to authorise a TPA. Any third party can provide a TPA. If no TPA is authorised by the user, then a device’s data is neither (e.g. Google, Facebook, Github, Twitter or any other shared nor stored. federated login). – The device: the device consists of one or more sensors – The user: A user may own one or more devices. A user and actuators together with a controller. Devices with must have at least one identity with a UIdP. sensors will publish sensor data.CSsmay subscribe to – The device identity provider (DIdP):thisisan Iden- this data if and only if users consent to it. Devices with tity Broker that first authenticates a user with a UIdP actuators will subscribe to commands. CSs may publish using existing federated identity protocols including commands to devices if and only if users consent to it. OAuth2, OpenID Connect (OIDC) or SAML2. Once – The manufacturer: the manufacturer is the logical the identity is validated, it then creates a secure ran- organisation that creates and markets the device, dom anonymous identity which is used in all further irrespective of whether they actually outsource any part processing. of the physical manufacturing to a third party. In this – Personal cloud middleware (PCM): this is an isolated model, the manufacturer configures each device with a broker that shares data between devices and third-party single DIdP. applications (TPAs) on behalf of the user. The PCM talks to the devices and the TPAs. Within the remit of The OAuth2 protocol [4] is a widely used federated a single OAuthing instance, there is one PCM per user. authentication and authorisation protocol. This model utilises the OAuth2 model as a basis for the identity and ownership of devices. While the system can support other protocols such as SAML and OpenID Connect for user User IdP (UIdP) login, the device is constrained to use only the OAuth2 * * protocol, as both those protocols impose too great an impact 1 for a constrained device [5]. One concern with IoT is that hardware devices can be compromised and secrets read * 1 Device IdP Manufacturer from them. It is therefore important that each device has (DIdP) its own credentials. We map each device to be a unique 1 1 OAuth2 Client, and we use the OAuth2 Client ID as a secure * * device ID that is only ever shared with the DIdP. We define * 1 * * Intelligent Gateway Third Party App ownership of a device by the user authorising the issuance Device (IG) (TPA) a security token to the device giving it permission to act on the user’s behalf. Figure 3 shows the UML sequence diagram of a runtime interaction between an owned device and a cloud service. Personal Cloud Middleware (PCM) 2.2 Lifecycle 1 * We modelled the lifecycle of a device. The UML lifecycle User diagram is shown in Fig. 4. Once the device is initially flashed, it is connected to a Fig. 2 Proposed model manufacturing server. The manufacturer then uses the DCR 418 Ann. Telecommun. (2018) 73:415–427 Fig. 3 Device publishing data to CS API into the DIdP to request a client ID and secret. These are configured into the device by the manufacturing server. At the same time, the DIdP returns a unique user registration Manufacture (the device is created) URL (URU) that is printed onto the device (usually as a QR code) by the manufacturer. When the user buys the device, they scan the QR code or Client Registration otherwise access the URU. This directs the user to the DIdP, (the device is registered with OAuThing as a OAuth2 client) which presents a choice of UIpDs to the user. Once the user is authorised with their existing UIpD, they are asked in turn to authorise the device. The resulting OAuth2 refresh Purchase token is then stored on the device and represents the logical (the device is physically in the hands of a user) ownership of the device. This flow is documented in the UML sequence diagram in Fig. 5. 2.3 Personal cloud middleware User Registration (the user takes ownership of the device and allocates it permissions) A key part of the model is the concept of a personal hub: where each user’s data is routed to its’ own hub, protecting the data from multi-tenant attacks. Each hub is run in its Use own virtualised cloud environment. When a request comes (the device is now publishing data and acting on user commands) in from a device or CS, we use the anonymous identity associated with the bearer token to route the request to an instance that is specific to that user. If there is no cloud reset ownership server available, the routing system makes a call to the cloud management system to instantiate a new PCM “on-demand” Fig. 4 Lifecycle of a device Ann. Telecommun. (2018) 73:415–427 419 capabilities, meaning that it is simpler for TPAs to connect User Device Device IdP UIdP to devices. Connect (Presence) 2.4 Scopes and APIs User scans QR code and connects to URU The DIdP implements consent-based authorisation policies Redirect to chosen UIdP called scopes, as defined in the OAuth2 specification. Each Login scope controls access to a set of APIs. These APIs may Redirect to DIdP be implemented in multiple protocols. Users may consent to a third party to have access to a specific scope, which request authorization is captured in a token. The model-defined APIs are shown Authorize in Fig. 6, together with the provider of the API and the authcode associated scope. One of the outcomes of defining scopes as part of this Client ID/Secret/Authcode model is that there is a clean mapping between the different refresh and access token roles in the system and the associated scopes, which is notify refresh token stored showninFig. 7. Success notification 2.5 Information visibility User Device Device IdP UIdP The model allows us to analyse which identifiers and data each participant has access to. A key aim of this model is Fig. 5 User registration sequence diagram to ensure that each party has a restricted view of a user’s and then waits until the instance is running before routing actions and therefore can only breach privacy in a limited the request to the PCM. In the model, the PCM supports way or with the help of a third party. routing and distribution of data and commands, as well as In Fig. 8, we identify each participant and show what summarisation and filtering of data. These capabilities have access they have to credentials, identities and data. an important role in protecting users privacy: firstly, the The manufacturer only knows the original device identity runtime does not inherently share data such as IP addresses (e.g. MAC address) and the client ID that was issued or MAC addresses that can be used to identify devices or at manufacturing time. Unless the user chooses to share users. Secondly, by filtering or summarising data, the PCM information with the manufacturer, then the manufacturer can avoid many fingerprinting attacks on devices [6]. The does not know the owner of the device and do not see any PCM can also provide protocol mapping and device shadow device data. Fig. 6 APIs 420 Ann. Telecommun. (2018) 73:415–427 Fig. 7 Mapping of scopes to participants The DIdP knows the original user profile as provided by The IG is given an anonymous random ID for the user, the UIdP. This is only used to ensure that two tokens issued through an Introspection API on the DIdP, which is only to the same user will result in messages being routed to available to IGs. The IG does not store any data. If it is the same PCM. The DIdP is aware of the device presence compromised, only data flowing through the system can (because the device must regularly refresh its tokens, and be stolen, and this cannot inherently be tied to a user or because the IG must introspect those tokens). However, the any device identifier. Both the IG and the DIdP would DIdP does not see any of the device data or commands. need to be compromised to tie that data to a specific The DIdP is aware of which TPAs a user is subscribed to, user. but does not know which devices are interacting with which The device and any TPAs are not aware of the user’s TPAs. In the event the DIdP is compromised, the attackers identity—they only see a refresh or bearer token and do cannot steal passwords or any user data—only the link not have the authorisation to call the introspection API. between the UIdP user identity and the anonymous identity. Therefore, a TPA cannot deduce the user’s identity from Fig. 8 Information visibility matrix Ann. Telecommun. (2018) 73:415–427 421 the OAuthing system. However, a TPA may be aware of 3.3 IGNITE the user’s identity through out-of-band means. For example, if the user decides to share their IoT data publicly on The prototype of the IG is called IGNITE (Intelligent a webpage, this webpage identifies them. Even in this Gateway for Network IoT Environments). IGNITE runs in case, the TPA does not know the device ID, only the data a Docker cloud container environment and has access to that is shared. Alternatively, the data itself may contain control this Docker environment. When a device or TPA ini- personally identifiable traits: this may be mitigated by tiates an MQTT connection with the CONNECT packet, sharing a summary or filtered data. Finally, the device data IGNITE first validates the bearer token by calling the DIdP’s itself is only visible to the device, the PCM and authorised introspection API. This either returns a random anonymous TPAs. ID together with a set of scopes or informs IGNITE that the token is invalid. IGNITE is then responsible for launching a new cloud instance to act as the PCM on behalf of the user, 3 Implementation or routing the request to the existing PCM. In order to validate the model, we built a prototype of the 3.4 Personal cloud middleware system. The following sections outline the components that were The PCM was implemented using the open source RSMB implemented to demonstrate the system. MQTT broker. This broker has a very low memory overhead and enabled us to run a significant number of 3.1 Protocol mapping PCM containers on standard hardware. We have not yet implemented summarisation and filtering on the PCM, The model has been designed to work independently which will potentially enlarge the memory footprint, but of specific protocols. However, in order to implement a we did not yet optimise the Docker runtime of the PCMs prototype, we needed to make specific choices on protocols. or the underlying operating system, and therefore, we are We also provide a mapping of part of the OAuth2 protocol confident that this can be offset. into MQTT [7] (an IoT-optimised protocol), allowing the device to utilise a single protocol for identity, authorisation 3.5 Device hardware and data. This simplifies the device coding and reduces the memory footprint of OAuthing support. We aimed to build the simplest possible device to provide a baseline evaluation of whether the model was 3.2 The OAuthing DIdP implementable on very small footprint devices. We chose the commonly available ESP8266 platform for our reference The prototype DIdP is called the OAuthing DIdP. device. This chip provides an embedded 32-bit processor, We implemented the OAuthing DIdP as a set of Wi-Fi connectivity and a number of digital inputs and containers running in the Docker container system, outputs for less than US$2.50 each (at the time of allowing it to be efficiently deployed and tested in a cloud writing). Currently, the ESP8266 supports TLS without full environment. certificate authority chains. Instead, it uses fingerprints of One of the key aims of our model is to preserve privacy. SSL certificates to validate them. In our implementation, we do not store any identifiable aspects of the user. Each UIdP provides the OAuthing IdP 3.6 Sample third-party application with an identifier. Rather than directly storing these identi- fiers, we create a new secure random anonymous identity In order to demonstrate this system, we also created a and store this against the hash of the UIdPs unique ID. simple web-based cloud service. This first connects to the A key difference between this and previous prototypes is OAuthing DIdP using a standard OAuth2 HTTP flow to that we implemented the MQTT APIs using an embedded request access to IGNITE. The user logs in using the broker pattern. In this model, the MQTT broker is part of the same UIdP that they registered their device with. After the OAuthing IdP. The major benefit of this approach is that the user authorises the Sample TPA to access IGNITE, the broker can implement a more secure model, especially when sample app is loaded. This uses MQTT over WebSockets to emulating request/response flows over the asynchronous MQTT protocol. Please note that there is another IoT framework with a similar name. These systems are unrelated and the system described here predates the other system: https://www.iot-ignite.com/ 1 3 http://www.docker.com https://github.com/eclipse/mosquitto.rsmb 422 Ann. Telecommun. (2018) 73:415–427 communicate and presents a simple UI, which allows users In order to simulate multiple clients for the latency and to interact with the device. TPS tests, we created a test harness designed to run across multiple cloud servers. The test harness consists of multiple test load drivers (TLDs). Each TLD can simulate one or 4 Evaluation more clients, emulating the network behaviour of the IoT device. The TLDs then report the performance and latency In this section, we present the results of testing both the data to a test manager. The test manager is running on a device and the cloud systems involved in the OAuthing separate instance, and this service collates the results. The prototype. Note that there was no optimisation of the TLDs implemented two different workloads: systems towards better performance: the system is a – One second client prototype and we did not perform profiling or optimisations. The one second client emulates a device that sends We therefore consider the results of these tests to be an one message per second. This is designed to test the upper bound on the extra costs of using OAuthing. system under moderate load. – Stress client 4.1 Test methodology The stress client emulates a device that sends messages continuously. This is designed to test the The test methodology was influenced by academic papers system under heavy load. both on middleware performance testing [8, 9]and commercial testing [10, 11]. Both tests time the latency between sending the message We identified four key measures for evaluating the from the device and receiving it in the TPA (or vice-versa). prototype. 4.2 Results – Transactions per second The total number of transactions per second (TPS) One clear result is that there is a working prototype of that a system can handle is the most common the model that demonstrates all aspects of this decoupled measurement of distributed systems. approach, including support on a low-cost device and a – Latency cloud implementation of the server-side components. The latency of a system measures how quickly the Figure 9 shows a simplified diagram of the test environ- system reacts. We measured the time taken from the ment, which is running in a public cloud environment. start of a publication process on the publisher to the Figure 10 shows the latency comparison of OAuthing time that the message is received at the subscriber. compared to the baseline system (Mosquitto) using the – Device memory one second client. Figure 11 shows the mean and 95% Devices often have constrained memory, and there- and 99% percentiles for the IGNITE latency responses fore, a key measure we identified was to understand in the same test. The graph demonstrates that OAuthing the memory requirements of our firmware and therefore shows consistently low latencies across all workloads. The the remaining memory available to device designers to additional latency added to message interactions compared implement their own logic. to Mosquitto was around 1 ms. The percentiles show that – Power consumption and energy usage 99% of requests had latency of less than 11 ms even when A key aspect for IoT devices is power consumption. the system was loaded with 400 test clients, and 95% of Many IoT devices (including the prototype system) run requests had latency less than 6 ms. Given that average off of a battery with a limited capacity and therefore round trip ping times over the Internet are in the 20–80- rely on using low power. We therefore created a test ms range, these results demonstrate that the overhead of the harness to accurately measure power usage and energy proposed approach is insignificant to users. consumed by our sample device. Further details of the The next data point collected was the maximum number power measurement system are described below. of PCMs that could be run on a single cloud server. The In all the tests described below, we ensured that the tests were run on a server with 2 GB of memory and no systems were warmed up and running and that all the swap configured, costing US$20/month. This environment results were repeatable across multiple tests. In addition, was able support at least 400 PCM instances, with the server we created a baseline system for comparison. The baseline running out of memory beyond 415 containers. Simply system does not use the OAuthing backend, but instead uses the commonly used Mosquitto MQTT server. All the tests were carried out using standard cloud server instances with A short video showing the registration and data-sharing process is fixed sizes from the Digital Ocean cloud provider. available at http://freo.me/oauthing-video Ann. Telecommun. (2018) 73:415–427 423 Fig. 9 Test environment adding swap will increase this number at the cost of some Figure 13 shows the performance of the OAuthing latency, but we have not yet evaluated this balance. system under stress. This shows that the server was handling Figure 12 shows the average connect time for three more than 4500 TPS at all levels and the average latency different scenarios. The fastest is the Mosquitto broker, rose to 83.3 ms when the system had 400 concurrent clients. with an average connect time of 24.5 ms. The slowest is This test demonstrates that the system as deployed in the the OAuthing when the user has not previously connected. test environment can support each user owning 600 devices In this scenario, the system needs to introspect the token each interacting once a minute, even when the system is and then wait until the new container is launched and fully loaded with 400 concurrent PCM containers. The ready. This takes on average 1294 ms (1.3 s). While this latency line shows that as new clients are added the latency is comparatively large, it happens rarely in the system and increases in direct proportion, demonstrating fair allocation in practice devices take between 2 and 10 s to connect to of resources. local Wi-Fi networks. This could be ameliorated by pre- Figure 14 shows the performance of the OAuthing IdP loading unused containers and associating them with users while issuing new Client IDs during manufacturing. This at connect time. is the least well-performing part of the system because we The third scenario is the connect time when there is chose to use a secure hashing algorithm (PBKDF2 [12]) to already a user container running. The average time here was ensure that our password database is resistant to dictionary 35.9 ms. The extra latency compared with Mosquitto (35.9 attacks. The result is that adding a client incurs considerable vs 24.5 ms) is well within acceptable ranges. CPU time. Fig. 10 One second client comparing OAuthing vs Mosquitto Fig. 11 One second client OAuthing percentiles 424 Ann. Telecommun. (2018) 73:415–427 Fig. 12 Device connect time We also performed performance tests measuring the latency and throughput of the DIdP under introspection, when the gateway asks the DIdP for the anonymous identity Fig. 14 Dynamic client registration latency and throughput and authorisation policies. This is presented in Fig. 15.The results show that the introspection service can successfully scale to support many IGs. Given that CSs and devices only of program memory for the developers of any device sensor connect intermittently (due to the persistent TCP session and actuator logic, which is sufficient to build complex model of MQTT), even a single DIdP server could handle device applications and support a variety of sensors and significant numbers of devices and third-party clients. actuators. We did not perform any code optimisation. 4.3 Device memory usage 4.4 Energy and power measurement The Arduino development environment that was used In order to test the additional power burden of using to create the device firmware provides statistics on the the OAuthing approach, we created a power measurement program and variable memory usage. Figure 16 shows the harness to evaluate the power usage of the system. program and variable memory usage of the ESP8266 when Traditional power measurement systems are not optimised loaded with the OAuthing sample device loader code. The for measuring sub-watt power usage and therefore, we could graph captures the usage of different components of the not use an off-the-shelf system. Figure 17 shows a logical loader. Each column includes the previous column. The diagram of the power management test system that we largest component is the base C libraries needed by the created. Arduino system, which take up 40% of variable memory and The created system measures milliwatt power usage with 24% of program memory. The next largest aspect is the TLS better than 1% accuracy. support which incrementally takes 5.5% of the program memory and 7.7% of the variable memory. Overall, the loader leaves over 38 k of variable memory and over 700 k Fig. 13 Stress client OAuthing performance Fig. 15 Throughput and latency of the introspection API on the DIdP Ann. Telecommun. (2018) 73:415–427 425 Fig. 16 ESP8266 memory usage We measured two different scenarios, comparing the Figure 19 shows the on-going power requirement is OAuthing device to the same device configured to talk to 26 mW higher for the OAuthing device, using 11.5% Mosquitto without using the OAuthing model more power than the device connecting to Mosquitto. This much extra power usage is slightly unexpected and requires – The first scenario was measuring the total energy usage further investigation. The ESP8266 offers three different from initial power-on until the first message is sent to low-power modes, none of which were implemented, and the server. This measures the bootstrap power phase, therefore, we expect the magnitude of this power usage to especially capturing the overhead of the refresh flow be significantly reduced in a production device. and the credential based MQTT CONNECT message. This is measured in milliwatt-hours. We ran each test 20 times. 5 Related work – The second scenario was the on-going power usage over the next 15 min after startup. To ensure both In [5], we previously looked at using federated identities for systems were comparable, we waited until the device IoT, especially mapping OAuth2 tokens to work with the was fully warmed up and then took 900 s of samples MQTT protocol. In a follow up work [13], we demonstrated (approximately 280,000 samples). the use of the dynamic client registration (DCR) API Figure 18 shows the time-to-first-message results. The to support each device having a unique OAuth2 client data shows that the OAuthing device took 0.68 s (5.7%) identifier. In each case, identifiers needed to be manually longer to send its first message, using 7.5% more energy added to the device, which is unrealistic in manufacturing (0.195 mWH) than when connecting to Mosquitto. processes. Existing public IoT middleware such as IBM Watson IoT and AWS IoT also have this concern. Compared to these previous works, this current model adds a clear automated device and user registration process. It also adds anonymous identities and personal cloud middleware. Fig. 17 Power management test system Fig. 18 Time and energy taken to bootstrap 426 Ann. Telecommun. (2018) 73:415–427 A key concern around the PCM model is that the cost per user might be too high. The prototype demonstrates that PCMs can be automatically deployed on behalf of the user with acceptable times. The experimental results demonstrate that a US$20/month cloud server can support 400 users, resulting in a cost per user of just $0.05 per month. Further optimisation could reduce this cost. The OAuthing model and prototype demonstrate that devices can be connected to TPAs without inherently leaking the user’s identity to either system. User’s may choose to provide TPAs with their identity, but that becomes a positive consent of the user rather than the default. In addition, users can bring pre-existing identities to the system Fig. 19 Power usage rather than being required to create new credentials, which reduces the chances of password theft and gives users a IOT-OAS [14] addresses the use of OAuth2 with the choice of identity provider. CoAP protocol. The mapping of the OAuth2 Token API We therefore assert that we have answered the research to support IoT devices using the CoAP protocol is being questions as follows: formalised in [15] and is described in [16]. In [17], there – RQ1: The OAuthing model and architecture provides is a demonstration of the OAuth1 protocol with MQTT, an approach whereby IoT networks can be decoupled. favouring OAuth1 over OAuth2 for IoT devices. The In particular, the identity and consent management can reasons for choosing the older OAuth protocol are obviated be decoupled from both the manufacturer and the data by the mapping of the refresh flow which OAuthing offers. sharing middleware, providing users with a choice of In [18]andin[19], there are platforms that support identity provider and of which systems they consent to OAuth2 for IoT devices that communicate via HTTP and share data with. WebSockets. None of these works address automated regis- – RQ2: The OAuthing model and prototype demonstrate tration processes, and none provide the privacy controls of that secure data sharing can happen between systems, anonymous identifiers or isolated personal cloud instances. including consent, without sharing identity as a pre- In [20], a capability-based access system is described that requisite. allows anonymous identities to be used. Bernabe et al. [21] – RQ3: We assert that the OAuthing model provides provides an architecture reference model for an approach significant improvements in privacy and security for that supports anonymous identities. Neither of these systems IoT networks over existing approaches, as discussed separates the provision of anonymous identities from the above. data-sharing middleware. – RQ4: The additional performance, latency, cost and The concept of a personal zone hub (PZH) is described energy usage of this model have been demonstrated to in the Webinos [22] system: this is similar to our PCM. be feasible. The overheads in terms of latency are within However, in Webinos, users must instantiate the PZH the norms of Internet latency, and the small overhead themselves, and there is no analysis of the cost per user. We in energy consumption is acceptable. All the data was extend the PZH concept to support a dynamic instantiation collected on a non-optimised prototype and therefore of PCMs as containers and provide a cost model. Webinos provides an upper bound to the overheads. does not address secure federated device identities and does not provide a registration process. There remain a number of unexplored aspects of this model. We expect to add tests that evaluate the performance of the OAuthing DIdP. In addition, we plan to extend 6 Discussion and conclusions the system to support multiple co-existing DIdPs. We have discussed this model with two significant device The OAuthing model provides significant improvements manufacturers. One potential concern is that some device over existing systems, providing much stronger guarantees manufacturers’ business models are based around collecting of privacy. Data and identity are not shared without consent, user data and therefore, this system is unattractive precisely and data can be shared anonymously. Device and user because it improves users privacy. However, there are a registration are automated, and the PCM model can prevent number of areas where this approach offers significant fingerprinting and sharing of IP and MAC addresses, as well benefits, for example in medical devices, where the as user and device identity. manufacturer does not wish to access data for regulatory Ann. Telecommun. (2018) 73:415–427 427 reasons. In addition, it is possible to start with the OAuthing 7. Locke D (2010) MQ Telemetry Transport (MQTT) V3.1 protocol specification. Tech. rep., IBM Corporation model and progressively lessen certain privacy controls to 8. Liu Y, Gorton I, Liu A, Jiang N, Chen S (2002) In: Proceedings of provide a system that still shares data but provides stronger the fortieth international conference on tools pacific: objects for guarantees. internet, mobile and embedded applications. Australian Computer We have identified a number of future items of research Society, Inc., pp 123–130 9. Jayaram K, Eugster P, Jayalath C (2013) Parametric content-based around this, including developing a full threat model publish/subscribe. ACM Trans Comput Syst (TOCS) 31(2):4 for the system; supporting devices that communicate via 10. AdroitLogic. Esb performance. http://esbperformance.org/ (2016). gateways (e.g. Bluetooth devices talking to a phone or Accessed 20 March 2017 hub); and demonstrating clustering and high-availability for 11. Council TPP Tpc. http://www.tpc.org/ (2017). Accessed 27 March the OAuthing DIdP and IGNITE. We have also identified 12. Kaliski B (2000) RFC 2898; PKCS# 5: Password-Based that further de-centralisation maybe possible by utilising Cryptography Specification Version 2.0 distributed ledger technologies such as Blockchains with the 13. Fremantle P, Kopecky´ J, Aziz B (2015) Web API mana- DIdP to reduce the requirement to have a central IdP for gement meets the Internet of Things. Springer International Pub- devices. lishing, Cham, pp 367–375. https://doi.org/10.1007/978-3-319- 25639-9 49 14. Cirani S, Picone M, Gonizzi P, Veltri L, Ferrari G (2015) Iot- oas: An oauth-based authorization service architecture for secure Open Access This article is distributed under the terms of the services in iot scenarios. IEEE Sensors J 15(2):1224 Creative Commons Attribution 4.0 International License (http:// 15. IETF Authentication and authorization for constrained envi- creativecommons.org/licenses/by/4.0/), which permits unrestricted ronments (ACE)—documents https://datatracker.ietf.org/wg/ace/ use, distribution, and reproduction in any medium, provided you give documents/ (2016). Accessed 30 Aug 2016 appropriate credit to the original author(s) and the source, provide a 16. Tschofenig H (2016) Datenschutz und Datensicherheit-DuD 40 link to the Creative Commons license, and indicate if changes were (4):222 made. 17. Niruntasukrat A, Issariyapat C, Pongpaibool P, Meesublak K, Aiumsupucgul P, Panya A (2016) In: 2016 IEEE International conference on communications workshops (ICC). IEEE, pp 290– References 18. Raggett D (2015) COMPOSE: An open source cloud-based scalable IoT services platform. ERCIM News 101:30 1. Wei J (2016) DDoS on Internet of Things–a big alarm for the 19. Emerson S, Choi YK, Hwang DY, Kim KS, Kim KH (2015) In: future 2015 International Conference on information and communication 2. Fremantle P, Scott P (2017) PeerJ Comput Sci 3:e114 technology convergence (ICTC). IEEE, pp 1072–1074 3. Rumbaugh J, Jacobson I, Booch G (2004) Unified modeling 20. Rotondi D, Seccia C, Piccione S (2011) 1st IoT International language reference manual. The Pearson Higher Education forum. Berlin 4. Hardt D (2012) The OAuth 2.0 authorization framework. Tech. 21. Bernabe JB, Hernandez ´ JL, Moreno MV, Gomez AFS (2014) In: rep. IETF International Conference on ubiquitous computing and ambient 5. Fremantle P, Aziz B, Scott P, Kopecky´ J (2014) In: 3rd intelligence. Springer, pp 408–415 International workshop on the secure IoT 22. Desruelle H, Lyle J, Isenberg S, Gielen F (2012) In: Proceedings 6. Kohno T, Broido A, Claffy KC (2005) Remote physical device of the 2012 ACM conference on ubiquitous computing. ACM, pp fingerprinting. IEEE Trans Depend Secur Comput 2(2):93 733–736 http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png Annals of Telecommunications Springer Journals

Cloud-based federated identity for the Internet of Things

Free
13 pages
Loading next page...
 
/lp/springer_journal/cloud-based-federated-identity-for-the-internet-of-things-P0IJuXes5f
Publisher
Springer International Publishing
Copyright
Copyright © 2018 by The Author(s)
Subject
Engineering; Communications Engineering, Networks; Information Systems and Communication Service; Signal,Image and Speech Processing; Computer Communication Networks; Information and Communication, Circuits; R & D/Technology Policy
ISSN
0003-4347
eISSN
1958-9395
D.O.I.
10.1007/s12243-018-0641-8
Publisher site
See Article on Publisher Site

Abstract

The Internet of Things (IoT) has significant security and privacy risks. Recent attacks have shown that not only are many IoT devices at risk of exploit, but those devices can be successfully used to attack wider systems and cause economic damage. Currently, most devices connect to a cloud service that is provided by the manufacturer of the device, offering no choice to move to more secure systems. We outline a proposed model for IoT that allows the identity of users and devices to be federated. Users and devices are issued with secure, random, anonymised identities that are not shared with third parties. We demonstrate how devices can be connected to third-party applications without inherently de-anonymising them. Sensor data and actuator commands are federated through APIs to cloud services. All access to device data and commands is based on explicit consent from users. Each user’s data is handled by a personal cloud instance providing improved security and isolation, as well as providing a trusted intermediary for both devices and cloud services. We demonstrate this model is workable with a prototype system that implements the major features of the model. We present experiment results including performance, energy usage, capacity and cost metrics from the prototype. We compare this work with other related work and outline areas for discussion and future work. Keywords Cloud computing · Distributed authentication and authorisation · Federated identity management · IoT 1 Introduction The result is that users are reliant on particular CSPs. These may be hacked, or may go out of business rendering Internet of Things (IoT) devices are proliferating throughout devices inoperable. A common attack on CSPs has been to the world, bringing with them a significant threat to privacy steal credentials and publish users’ passwords. Hacked devices not only can be used to steal personal and security. There are multiple concerns with IoT devices. One of the key issues in the IoT space is the concern that data but also can be used to launch attacks on other when a device is purchased, it is tied to a specific web systems. In late 2016, large parts of the US East Coast system or cloud service, which is owned and managed by a Internet were disabled by a distributed denial of service cloud service provider (CSP). attack (DDoS), launched from a botnet running across In traditional Internet systems, users can migrate away approximately 100,000 IoT devices including IP-enabled from insecure services, because of interoperability and CCTV cameras [1]. choice. For example, the instant messaging market has seen In addition, there are other security and privacy con- the emergence of a number of more secure systems, includ- cerns. Small, inexpensive and/or low-power devices do not ing WhatsApp, Signal and Threema. In the IoT, the devices properly support encryption allowing communications to are often hard-coded to work with only specific Inter- be stolen. Few devices use well-defined identity models, meaning that spoofing attacks are possible. Data may be net systems, using private protocols and specific servers. validly shared by multiple cloud services but then aggre- gated to de-anonymise user information and infringe on Paul Fremantle privacy. We have previously identified a number of secu- paul.fremantle@port.ac.uk rity and privacy concerns with IoT which are documented Benjamin Aziz in [2]. benjamin.aziz@port.ac.uk We outline a new model, together with a prototype and 1 experimental results that aims to address these issues. We School of Computing, University of Portsmouth, call this model OAuthing. Portsmouth, UK 416 Ann. Telecommun. (2018) 73:415–427 1.1 Aims and objectives to cover a significant portion of this space, we have chosen to restrict the effort to cover: Based on the privacy and security concerns identified above, – Devices with a direct TCP/IP connection to the Internet the following research questions were identified: – Devices that can be owned or managed by a single – RQ1: Is there a model and architecture for IoT that person effectively federates identity and consent management? – Systems where the privacy of the data is relevant to the – RQ2: Can we provide pseudonymous access to IoT owner of a device. systems such that identity is not implicitly shared even For example, this work does not yet address devices in secure flows? where the device connects via bridging through an app on a – RQ3: Does this approach provide improved privacy and mobile phone or via a device gateway. However, the app on security for IoT networks? the phone or the local gateway could be secured using this – RQ4: Can this approach be implemented without model. adding an infeasible burden to the performance, cost and energy usage of an IoT network? 1.4 Outline of the paper The aim of this work is to answer these four research questions. The remainder of this paper continues with the following organisation. In Section 2, we propose a model of the 1.2 Contributions different parties involved and an architecture that supports decoupling of different actors in the environment. In The contributions of this work in addressing these issues Section 3, we outline a prototype middleware system that we include the following: have created to implement this model, alongside prototype devices and cloud services that demonstrate end-to-end – An architecture and system model that allows the flows. In Section 4, we outline the experimental results, federation of multiple parties: the manufacturer, the together with the test harness that was built to gather identity provider, the device identity management, and data. We discuss the related work and compare it to our cloud services and applications that require access to results in Section 5. In Section 6, we analyse the outcomes IoT data. This federation and decoupling encourages of the experimental results and the overall model. We choice of provider as well as reducing the data available also outline a set of further work identified during this in any given attack. research. – Clearly defined device and user registration processes, based on the OAuth2 protocol, that have been extended to support IoT devices and be effective in device 2Model scenarios. – A model for providing anonymous identities for users, In the following section, we outline a model—called reducing the chance that leaked data can be tied to OAuthing—that aims to federate identity and consent users. management for IoT systems. We utilise the UML2 [3] – An architecture that provides each user with a separate graphical modelling notation to model the participants and cloud instance to handle sharing device data, and an flows of this approach. approach for dynamically provisioning these cloud instances. 2.1 Participants – A demonstration of the workability of the model through the creation of a working prototype, together Figure 1 shows the current situation for many IoT systems, with a test harness. where there is no federation and the device talks to a single – Experimental results on the including energy usage, service that manages identity, stores data, provides a user performance, cost and capacity metrics of the prototype. web interface etc. By comparison, the federated model we present in 1.3 Assumptions and scope Fig. 2 allows different federated parties to provide different services that work together. The Internet of Things encompasses a vast array of The participants of the OAuthing model are as follows: environments, from small devices that connect over low- power protocols like Bluetooth LE, to industrial monitoring – The user identity provider (UIdP): this is an existing devices. While we believe that this work could be extended login system where users present their credentials Ann. Telecommun. (2018) 73:415–427 417 We utilise a cloud environment to dynamically launch PCM instances on behalf of users as needed. – Intelligent gateway (IG): the IG interfaces with the DIdP to validate identities and access authorisation policies and to the cloud infrastructure to instantiate new PCMs. Devices and CSs connect to the IG, and it routes requests to each user’s PCM. – Third-party application (TPA): a device is an IoT device if and only if it shares or receives data and commands with an Internet service. Users control which TPAs can access their sensor data or control Fig. 1 Existing approach for IoT device cloud their actuators by explicitly consenting to authorise a TPA. Any third party can provide a TPA. If no TPA is authorised by the user, then a device’s data is neither (e.g. Google, Facebook, Github, Twitter or any other shared nor stored. federated login). – The device: the device consists of one or more sensors – The user: A user may own one or more devices. A user and actuators together with a controller. Devices with must have at least one identity with a UIdP. sensors will publish sensor data.CSsmay subscribe to – The device identity provider (DIdP):thisisan Iden- this data if and only if users consent to it. Devices with tity Broker that first authenticates a user with a UIdP actuators will subscribe to commands. CSs may publish using existing federated identity protocols including commands to devices if and only if users consent to it. OAuth2, OpenID Connect (OIDC) or SAML2. Once – The manufacturer: the manufacturer is the logical the identity is validated, it then creates a secure ran- organisation that creates and markets the device, dom anonymous identity which is used in all further irrespective of whether they actually outsource any part processing. of the physical manufacturing to a third party. In this – Personal cloud middleware (PCM): this is an isolated model, the manufacturer configures each device with a broker that shares data between devices and third-party single DIdP. applications (TPAs) on behalf of the user. The PCM talks to the devices and the TPAs. Within the remit of The OAuth2 protocol [4] is a widely used federated a single OAuthing instance, there is one PCM per user. authentication and authorisation protocol. This model utilises the OAuth2 model as a basis for the identity and ownership of devices. While the system can support other protocols such as SAML and OpenID Connect for user User IdP (UIdP) login, the device is constrained to use only the OAuth2 * * protocol, as both those protocols impose too great an impact 1 for a constrained device [5]. One concern with IoT is that hardware devices can be compromised and secrets read * 1 Device IdP Manufacturer from them. It is therefore important that each device has (DIdP) its own credentials. We map each device to be a unique 1 1 OAuth2 Client, and we use the OAuth2 Client ID as a secure * * device ID that is only ever shared with the DIdP. We define * 1 * * Intelligent Gateway Third Party App ownership of a device by the user authorising the issuance Device (IG) (TPA) a security token to the device giving it permission to act on the user’s behalf. Figure 3 shows the UML sequence diagram of a runtime interaction between an owned device and a cloud service. Personal Cloud Middleware (PCM) 2.2 Lifecycle 1 * We modelled the lifecycle of a device. The UML lifecycle User diagram is shown in Fig. 4. Once the device is initially flashed, it is connected to a Fig. 2 Proposed model manufacturing server. The manufacturer then uses the DCR 418 Ann. Telecommun. (2018) 73:415–427 Fig. 3 Device publishing data to CS API into the DIdP to request a client ID and secret. These are configured into the device by the manufacturing server. At the same time, the DIdP returns a unique user registration Manufacture (the device is created) URL (URU) that is printed onto the device (usually as a QR code) by the manufacturer. When the user buys the device, they scan the QR code or Client Registration otherwise access the URU. This directs the user to the DIdP, (the device is registered with OAuThing as a OAuth2 client) which presents a choice of UIpDs to the user. Once the user is authorised with their existing UIpD, they are asked in turn to authorise the device. The resulting OAuth2 refresh Purchase token is then stored on the device and represents the logical (the device is physically in the hands of a user) ownership of the device. This flow is documented in the UML sequence diagram in Fig. 5. 2.3 Personal cloud middleware User Registration (the user takes ownership of the device and allocates it permissions) A key part of the model is the concept of a personal hub: where each user’s data is routed to its’ own hub, protecting the data from multi-tenant attacks. Each hub is run in its Use own virtualised cloud environment. When a request comes (the device is now publishing data and acting on user commands) in from a device or CS, we use the anonymous identity associated with the bearer token to route the request to an instance that is specific to that user. If there is no cloud reset ownership server available, the routing system makes a call to the cloud management system to instantiate a new PCM “on-demand” Fig. 4 Lifecycle of a device Ann. Telecommun. (2018) 73:415–427 419 capabilities, meaning that it is simpler for TPAs to connect User Device Device IdP UIdP to devices. Connect (Presence) 2.4 Scopes and APIs User scans QR code and connects to URU The DIdP implements consent-based authorisation policies Redirect to chosen UIdP called scopes, as defined in the OAuth2 specification. Each Login scope controls access to a set of APIs. These APIs may Redirect to DIdP be implemented in multiple protocols. Users may consent to a third party to have access to a specific scope, which request authorization is captured in a token. The model-defined APIs are shown Authorize in Fig. 6, together with the provider of the API and the authcode associated scope. One of the outcomes of defining scopes as part of this Client ID/Secret/Authcode model is that there is a clean mapping between the different refresh and access token roles in the system and the associated scopes, which is notify refresh token stored showninFig. 7. Success notification 2.5 Information visibility User Device Device IdP UIdP The model allows us to analyse which identifiers and data each participant has access to. A key aim of this model is Fig. 5 User registration sequence diagram to ensure that each party has a restricted view of a user’s and then waits until the instance is running before routing actions and therefore can only breach privacy in a limited the request to the PCM. In the model, the PCM supports way or with the help of a third party. routing and distribution of data and commands, as well as In Fig. 8, we identify each participant and show what summarisation and filtering of data. These capabilities have access they have to credentials, identities and data. an important role in protecting users privacy: firstly, the The manufacturer only knows the original device identity runtime does not inherently share data such as IP addresses (e.g. MAC address) and the client ID that was issued or MAC addresses that can be used to identify devices or at manufacturing time. Unless the user chooses to share users. Secondly, by filtering or summarising data, the PCM information with the manufacturer, then the manufacturer can avoid many fingerprinting attacks on devices [6]. The does not know the owner of the device and do not see any PCM can also provide protocol mapping and device shadow device data. Fig. 6 APIs 420 Ann. Telecommun. (2018) 73:415–427 Fig. 7 Mapping of scopes to participants The DIdP knows the original user profile as provided by The IG is given an anonymous random ID for the user, the UIdP. This is only used to ensure that two tokens issued through an Introspection API on the DIdP, which is only to the same user will result in messages being routed to available to IGs. The IG does not store any data. If it is the same PCM. The DIdP is aware of the device presence compromised, only data flowing through the system can (because the device must regularly refresh its tokens, and be stolen, and this cannot inherently be tied to a user or because the IG must introspect those tokens). However, the any device identifier. Both the IG and the DIdP would DIdP does not see any of the device data or commands. need to be compromised to tie that data to a specific The DIdP is aware of which TPAs a user is subscribed to, user. but does not know which devices are interacting with which The device and any TPAs are not aware of the user’s TPAs. In the event the DIdP is compromised, the attackers identity—they only see a refresh or bearer token and do cannot steal passwords or any user data—only the link not have the authorisation to call the introspection API. between the UIdP user identity and the anonymous identity. Therefore, a TPA cannot deduce the user’s identity from Fig. 8 Information visibility matrix Ann. Telecommun. (2018) 73:415–427 421 the OAuthing system. However, a TPA may be aware of 3.3 IGNITE the user’s identity through out-of-band means. For example, if the user decides to share their IoT data publicly on The prototype of the IG is called IGNITE (Intelligent a webpage, this webpage identifies them. Even in this Gateway for Network IoT Environments). IGNITE runs in case, the TPA does not know the device ID, only the data a Docker cloud container environment and has access to that is shared. Alternatively, the data itself may contain control this Docker environment. When a device or TPA ini- personally identifiable traits: this may be mitigated by tiates an MQTT connection with the CONNECT packet, sharing a summary or filtered data. Finally, the device data IGNITE first validates the bearer token by calling the DIdP’s itself is only visible to the device, the PCM and authorised introspection API. This either returns a random anonymous TPAs. ID together with a set of scopes or informs IGNITE that the token is invalid. IGNITE is then responsible for launching a new cloud instance to act as the PCM on behalf of the user, 3 Implementation or routing the request to the existing PCM. In order to validate the model, we built a prototype of the 3.4 Personal cloud middleware system. The following sections outline the components that were The PCM was implemented using the open source RSMB implemented to demonstrate the system. MQTT broker. This broker has a very low memory overhead and enabled us to run a significant number of 3.1 Protocol mapping PCM containers on standard hardware. We have not yet implemented summarisation and filtering on the PCM, The model has been designed to work independently which will potentially enlarge the memory footprint, but of specific protocols. However, in order to implement a we did not yet optimise the Docker runtime of the PCMs prototype, we needed to make specific choices on protocols. or the underlying operating system, and therefore, we are We also provide a mapping of part of the OAuth2 protocol confident that this can be offset. into MQTT [7] (an IoT-optimised protocol), allowing the device to utilise a single protocol for identity, authorisation 3.5 Device hardware and data. This simplifies the device coding and reduces the memory footprint of OAuthing support. We aimed to build the simplest possible device to provide a baseline evaluation of whether the model was 3.2 The OAuthing DIdP implementable on very small footprint devices. We chose the commonly available ESP8266 platform for our reference The prototype DIdP is called the OAuthing DIdP. device. This chip provides an embedded 32-bit processor, We implemented the OAuthing DIdP as a set of Wi-Fi connectivity and a number of digital inputs and containers running in the Docker container system, outputs for less than US$2.50 each (at the time of allowing it to be efficiently deployed and tested in a cloud writing). Currently, the ESP8266 supports TLS without full environment. certificate authority chains. Instead, it uses fingerprints of One of the key aims of our model is to preserve privacy. SSL certificates to validate them. In our implementation, we do not store any identifiable aspects of the user. Each UIdP provides the OAuthing IdP 3.6 Sample third-party application with an identifier. Rather than directly storing these identi- fiers, we create a new secure random anonymous identity In order to demonstrate this system, we also created a and store this against the hash of the UIdPs unique ID. simple web-based cloud service. This first connects to the A key difference between this and previous prototypes is OAuthing DIdP using a standard OAuth2 HTTP flow to that we implemented the MQTT APIs using an embedded request access to IGNITE. The user logs in using the broker pattern. In this model, the MQTT broker is part of the same UIdP that they registered their device with. After the OAuthing IdP. The major benefit of this approach is that the user authorises the Sample TPA to access IGNITE, the broker can implement a more secure model, especially when sample app is loaded. This uses MQTT over WebSockets to emulating request/response flows over the asynchronous MQTT protocol. Please note that there is another IoT framework with a similar name. These systems are unrelated and the system described here predates the other system: https://www.iot-ignite.com/ 1 3 http://www.docker.com https://github.com/eclipse/mosquitto.rsmb 422 Ann. Telecommun. (2018) 73:415–427 communicate and presents a simple UI, which allows users In order to simulate multiple clients for the latency and to interact with the device. TPS tests, we created a test harness designed to run across multiple cloud servers. The test harness consists of multiple test load drivers (TLDs). Each TLD can simulate one or 4 Evaluation more clients, emulating the network behaviour of the IoT device. The TLDs then report the performance and latency In this section, we present the results of testing both the data to a test manager. The test manager is running on a device and the cloud systems involved in the OAuthing separate instance, and this service collates the results. The prototype. Note that there was no optimisation of the TLDs implemented two different workloads: systems towards better performance: the system is a – One second client prototype and we did not perform profiling or optimisations. The one second client emulates a device that sends We therefore consider the results of these tests to be an one message per second. This is designed to test the upper bound on the extra costs of using OAuthing. system under moderate load. – Stress client 4.1 Test methodology The stress client emulates a device that sends messages continuously. This is designed to test the The test methodology was influenced by academic papers system under heavy load. both on middleware performance testing [8, 9]and commercial testing [10, 11]. Both tests time the latency between sending the message We identified four key measures for evaluating the from the device and receiving it in the TPA (or vice-versa). prototype. 4.2 Results – Transactions per second The total number of transactions per second (TPS) One clear result is that there is a working prototype of that a system can handle is the most common the model that demonstrates all aspects of this decoupled measurement of distributed systems. approach, including support on a low-cost device and a – Latency cloud implementation of the server-side components. The latency of a system measures how quickly the Figure 9 shows a simplified diagram of the test environ- system reacts. We measured the time taken from the ment, which is running in a public cloud environment. start of a publication process on the publisher to the Figure 10 shows the latency comparison of OAuthing time that the message is received at the subscriber. compared to the baseline system (Mosquitto) using the – Device memory one second client. Figure 11 shows the mean and 95% Devices often have constrained memory, and there- and 99% percentiles for the IGNITE latency responses fore, a key measure we identified was to understand in the same test. The graph demonstrates that OAuthing the memory requirements of our firmware and therefore shows consistently low latencies across all workloads. The the remaining memory available to device designers to additional latency added to message interactions compared implement their own logic. to Mosquitto was around 1 ms. The percentiles show that – Power consumption and energy usage 99% of requests had latency of less than 11 ms even when A key aspect for IoT devices is power consumption. the system was loaded with 400 test clients, and 95% of Many IoT devices (including the prototype system) run requests had latency less than 6 ms. Given that average off of a battery with a limited capacity and therefore round trip ping times over the Internet are in the 20–80- rely on using low power. We therefore created a test ms range, these results demonstrate that the overhead of the harness to accurately measure power usage and energy proposed approach is insignificant to users. consumed by our sample device. Further details of the The next data point collected was the maximum number power measurement system are described below. of PCMs that could be run on a single cloud server. The In all the tests described below, we ensured that the tests were run on a server with 2 GB of memory and no systems were warmed up and running and that all the swap configured, costing US$20/month. This environment results were repeatable across multiple tests. In addition, was able support at least 400 PCM instances, with the server we created a baseline system for comparison. The baseline running out of memory beyond 415 containers. Simply system does not use the OAuthing backend, but instead uses the commonly used Mosquitto MQTT server. All the tests were carried out using standard cloud server instances with A short video showing the registration and data-sharing process is fixed sizes from the Digital Ocean cloud provider. available at http://freo.me/oauthing-video Ann. Telecommun. (2018) 73:415–427 423 Fig. 9 Test environment adding swap will increase this number at the cost of some Figure 13 shows the performance of the OAuthing latency, but we have not yet evaluated this balance. system under stress. This shows that the server was handling Figure 12 shows the average connect time for three more than 4500 TPS at all levels and the average latency different scenarios. The fastest is the Mosquitto broker, rose to 83.3 ms when the system had 400 concurrent clients. with an average connect time of 24.5 ms. The slowest is This test demonstrates that the system as deployed in the the OAuthing when the user has not previously connected. test environment can support each user owning 600 devices In this scenario, the system needs to introspect the token each interacting once a minute, even when the system is and then wait until the new container is launched and fully loaded with 400 concurrent PCM containers. The ready. This takes on average 1294 ms (1.3 s). While this latency line shows that as new clients are added the latency is comparatively large, it happens rarely in the system and increases in direct proportion, demonstrating fair allocation in practice devices take between 2 and 10 s to connect to of resources. local Wi-Fi networks. This could be ameliorated by pre- Figure 14 shows the performance of the OAuthing IdP loading unused containers and associating them with users while issuing new Client IDs during manufacturing. This at connect time. is the least well-performing part of the system because we The third scenario is the connect time when there is chose to use a secure hashing algorithm (PBKDF2 [12]) to already a user container running. The average time here was ensure that our password database is resistant to dictionary 35.9 ms. The extra latency compared with Mosquitto (35.9 attacks. The result is that adding a client incurs considerable vs 24.5 ms) is well within acceptable ranges. CPU time. Fig. 10 One second client comparing OAuthing vs Mosquitto Fig. 11 One second client OAuthing percentiles 424 Ann. Telecommun. (2018) 73:415–427 Fig. 12 Device connect time We also performed performance tests measuring the latency and throughput of the DIdP under introspection, when the gateway asks the DIdP for the anonymous identity Fig. 14 Dynamic client registration latency and throughput and authorisation policies. This is presented in Fig. 15.The results show that the introspection service can successfully scale to support many IGs. Given that CSs and devices only of program memory for the developers of any device sensor connect intermittently (due to the persistent TCP session and actuator logic, which is sufficient to build complex model of MQTT), even a single DIdP server could handle device applications and support a variety of sensors and significant numbers of devices and third-party clients. actuators. We did not perform any code optimisation. 4.3 Device memory usage 4.4 Energy and power measurement The Arduino development environment that was used In order to test the additional power burden of using to create the device firmware provides statistics on the the OAuthing approach, we created a power measurement program and variable memory usage. Figure 16 shows the harness to evaluate the power usage of the system. program and variable memory usage of the ESP8266 when Traditional power measurement systems are not optimised loaded with the OAuthing sample device loader code. The for measuring sub-watt power usage and therefore, we could graph captures the usage of different components of the not use an off-the-shelf system. Figure 17 shows a logical loader. Each column includes the previous column. The diagram of the power management test system that we largest component is the base C libraries needed by the created. Arduino system, which take up 40% of variable memory and The created system measures milliwatt power usage with 24% of program memory. The next largest aspect is the TLS better than 1% accuracy. support which incrementally takes 5.5% of the program memory and 7.7% of the variable memory. Overall, the loader leaves over 38 k of variable memory and over 700 k Fig. 13 Stress client OAuthing performance Fig. 15 Throughput and latency of the introspection API on the DIdP Ann. Telecommun. (2018) 73:415–427 425 Fig. 16 ESP8266 memory usage We measured two different scenarios, comparing the Figure 19 shows the on-going power requirement is OAuthing device to the same device configured to talk to 26 mW higher for the OAuthing device, using 11.5% Mosquitto without using the OAuthing model more power than the device connecting to Mosquitto. This much extra power usage is slightly unexpected and requires – The first scenario was measuring the total energy usage further investigation. The ESP8266 offers three different from initial power-on until the first message is sent to low-power modes, none of which were implemented, and the server. This measures the bootstrap power phase, therefore, we expect the magnitude of this power usage to especially capturing the overhead of the refresh flow be significantly reduced in a production device. and the credential based MQTT CONNECT message. This is measured in milliwatt-hours. We ran each test 20 times. 5 Related work – The second scenario was the on-going power usage over the next 15 min after startup. To ensure both In [5], we previously looked at using federated identities for systems were comparable, we waited until the device IoT, especially mapping OAuth2 tokens to work with the was fully warmed up and then took 900 s of samples MQTT protocol. In a follow up work [13], we demonstrated (approximately 280,000 samples). the use of the dynamic client registration (DCR) API Figure 18 shows the time-to-first-message results. The to support each device having a unique OAuth2 client data shows that the OAuthing device took 0.68 s (5.7%) identifier. In each case, identifiers needed to be manually longer to send its first message, using 7.5% more energy added to the device, which is unrealistic in manufacturing (0.195 mWH) than when connecting to Mosquitto. processes. Existing public IoT middleware such as IBM Watson IoT and AWS IoT also have this concern. Compared to these previous works, this current model adds a clear automated device and user registration process. It also adds anonymous identities and personal cloud middleware. Fig. 17 Power management test system Fig. 18 Time and energy taken to bootstrap 426 Ann. Telecommun. (2018) 73:415–427 A key concern around the PCM model is that the cost per user might be too high. The prototype demonstrates that PCMs can be automatically deployed on behalf of the user with acceptable times. The experimental results demonstrate that a US$20/month cloud server can support 400 users, resulting in a cost per user of just $0.05 per month. Further optimisation could reduce this cost. The OAuthing model and prototype demonstrate that devices can be connected to TPAs without inherently leaking the user’s identity to either system. User’s may choose to provide TPAs with their identity, but that becomes a positive consent of the user rather than the default. In addition, users can bring pre-existing identities to the system Fig. 19 Power usage rather than being required to create new credentials, which reduces the chances of password theft and gives users a IOT-OAS [14] addresses the use of OAuth2 with the choice of identity provider. CoAP protocol. The mapping of the OAuth2 Token API We therefore assert that we have answered the research to support IoT devices using the CoAP protocol is being questions as follows: formalised in [15] and is described in [16]. In [17], there – RQ1: The OAuthing model and architecture provides is a demonstration of the OAuth1 protocol with MQTT, an approach whereby IoT networks can be decoupled. favouring OAuth1 over OAuth2 for IoT devices. The In particular, the identity and consent management can reasons for choosing the older OAuth protocol are obviated be decoupled from both the manufacturer and the data by the mapping of the refresh flow which OAuthing offers. sharing middleware, providing users with a choice of In [18]andin[19], there are platforms that support identity provider and of which systems they consent to OAuth2 for IoT devices that communicate via HTTP and share data with. WebSockets. None of these works address automated regis- – RQ2: The OAuthing model and prototype demonstrate tration processes, and none provide the privacy controls of that secure data sharing can happen between systems, anonymous identifiers or isolated personal cloud instances. including consent, without sharing identity as a pre- In [20], a capability-based access system is described that requisite. allows anonymous identities to be used. Bernabe et al. [21] – RQ3: We assert that the OAuthing model provides provides an architecture reference model for an approach significant improvements in privacy and security for that supports anonymous identities. Neither of these systems IoT networks over existing approaches, as discussed separates the provision of anonymous identities from the above. data-sharing middleware. – RQ4: The additional performance, latency, cost and The concept of a personal zone hub (PZH) is described energy usage of this model have been demonstrated to in the Webinos [22] system: this is similar to our PCM. be feasible. The overheads in terms of latency are within However, in Webinos, users must instantiate the PZH the norms of Internet latency, and the small overhead themselves, and there is no analysis of the cost per user. We in energy consumption is acceptable. All the data was extend the PZH concept to support a dynamic instantiation collected on a non-optimised prototype and therefore of PCMs as containers and provide a cost model. Webinos provides an upper bound to the overheads. does not address secure federated device identities and does not provide a registration process. There remain a number of unexplored aspects of this model. We expect to add tests that evaluate the performance of the OAuthing DIdP. In addition, we plan to extend 6 Discussion and conclusions the system to support multiple co-existing DIdPs. We have discussed this model with two significant device The OAuthing model provides significant improvements manufacturers. One potential concern is that some device over existing systems, providing much stronger guarantees manufacturers’ business models are based around collecting of privacy. Data and identity are not shared without consent, user data and therefore, this system is unattractive precisely and data can be shared anonymously. Device and user because it improves users privacy. However, there are a registration are automated, and the PCM model can prevent number of areas where this approach offers significant fingerprinting and sharing of IP and MAC addresses, as well benefits, for example in medical devices, where the as user and device identity. manufacturer does not wish to access data for regulatory Ann. Telecommun. (2018) 73:415–427 427 reasons. In addition, it is possible to start with the OAuthing 7. Locke D (2010) MQ Telemetry Transport (MQTT) V3.1 protocol specification. Tech. rep., IBM Corporation model and progressively lessen certain privacy controls to 8. Liu Y, Gorton I, Liu A, Jiang N, Chen S (2002) In: Proceedings of provide a system that still shares data but provides stronger the fortieth international conference on tools pacific: objects for guarantees. internet, mobile and embedded applications. Australian Computer We have identified a number of future items of research Society, Inc., pp 123–130 9. Jayaram K, Eugster P, Jayalath C (2013) Parametric content-based around this, including developing a full threat model publish/subscribe. ACM Trans Comput Syst (TOCS) 31(2):4 for the system; supporting devices that communicate via 10. AdroitLogic. Esb performance. http://esbperformance.org/ (2016). gateways (e.g. Bluetooth devices talking to a phone or Accessed 20 March 2017 hub); and demonstrating clustering and high-availability for 11. Council TPP Tpc. http://www.tpc.org/ (2017). Accessed 27 March the OAuthing DIdP and IGNITE. We have also identified 12. Kaliski B (2000) RFC 2898; PKCS# 5: Password-Based that further de-centralisation maybe possible by utilising Cryptography Specification Version 2.0 distributed ledger technologies such as Blockchains with the 13. Fremantle P, Kopecky´ J, Aziz B (2015) Web API mana- DIdP to reduce the requirement to have a central IdP for gement meets the Internet of Things. Springer International Pub- devices. lishing, Cham, pp 367–375. https://doi.org/10.1007/978-3-319- 25639-9 49 14. Cirani S, Picone M, Gonizzi P, Veltri L, Ferrari G (2015) Iot- oas: An oauth-based authorization service architecture for secure Open Access This article is distributed under the terms of the services in iot scenarios. IEEE Sensors J 15(2):1224 Creative Commons Attribution 4.0 International License (http:// 15. IETF Authentication and authorization for constrained envi- creativecommons.org/licenses/by/4.0/), which permits unrestricted ronments (ACE)—documents https://datatracker.ietf.org/wg/ace/ use, distribution, and reproduction in any medium, provided you give documents/ (2016). Accessed 30 Aug 2016 appropriate credit to the original author(s) and the source, provide a 16. Tschofenig H (2016) Datenschutz und Datensicherheit-DuD 40 link to the Creative Commons license, and indicate if changes were (4):222 made. 17. Niruntasukrat A, Issariyapat C, Pongpaibool P, Meesublak K, Aiumsupucgul P, Panya A (2016) In: 2016 IEEE International conference on communications workshops (ICC). IEEE, pp 290– References 18. Raggett D (2015) COMPOSE: An open source cloud-based scalable IoT services platform. ERCIM News 101:30 1. Wei J (2016) DDoS on Internet of Things–a big alarm for the 19. Emerson S, Choi YK, Hwang DY, Kim KS, Kim KH (2015) In: future 2015 International Conference on information and communication 2. Fremantle P, Scott P (2017) PeerJ Comput Sci 3:e114 technology convergence (ICTC). IEEE, pp 1072–1074 3. Rumbaugh J, Jacobson I, Booch G (2004) Unified modeling 20. Rotondi D, Seccia C, Piccione S (2011) 1st IoT International language reference manual. The Pearson Higher Education forum. Berlin 4. Hardt D (2012) The OAuth 2.0 authorization framework. Tech. 21. Bernabe JB, Hernandez ´ JL, Moreno MV, Gomez AFS (2014) In: rep. IETF International Conference on ubiquitous computing and ambient 5. Fremantle P, Aziz B, Scott P, Kopecky´ J (2014) In: 3rd intelligence. Springer, pp 408–415 International workshop on the secure IoT 22. Desruelle H, Lyle J, Isenberg S, Gielen F (2012) In: Proceedings 6. Kohno T, Broido A, Claffy KC (2005) Remote physical device of the 2012 ACM conference on ubiquitous computing. ACM, pp fingerprinting. IEEE Trans Depend Secur Comput 2(2):93 733–736

Journal

Annals of TelecommunicationsSpringer Journals

Published: May 29, 2018

References

You’re reading a free preview. Subscribe to read the entire article.


DeepDyve is your
personal research library

It’s your single place to instantly
discover and read the research
that matters to you.

Enjoy affordable access to
over 18 million articles from more than
15,000 peer-reviewed journals.

All for just $49/month

Explore the DeepDyve Library

Search

Query the DeepDyve database, plus search all of PubMed and Google Scholar seamlessly

Organize

Save any article or search result from DeepDyve, PubMed, and Google Scholar... all in one place.

Access

Get unlimited, online access to over 18 million full-text articles from more than 15,000 scientific journals.

Your journals are on DeepDyve

Read from thousands of the leading scholarly journals from SpringerNature, Elsevier, Wiley-Blackwell, Oxford University Press and more.

All the latest content is available, no embargo periods.

See the journals in your area

DeepDyve

Freelancer

DeepDyve

Pro

Price

FREE

$49/month
$360/year

Save searches from
Google Scholar,
PubMed

Create lists to
organize your research

Export lists, citations

Read DeepDyve articles

Abstract access only

Unlimited access to over
18 million full-text articles

Print

20 pages / month

PDF Discount

20% off