Security in Internet of Things using Delegation of Trust to a Provisioning Server

Security in Internet of Things using Delegation of Trust to a Provisioning Server Architecture overview Peter Waher Clayster Laboratorios Chile S.A, Blanco 1623, of. 1402, Valparaíso, Chile peter.waher@clayster.com Abstract. This paper proposes an architecture for open networks, such as the Internet of Things, and describes an implemented solution that allows Things with limited or no user interfaces to provide a high level of data security, by delegating trust to a trusted third party to help the device determine which users, devices or services are authorized to perform what operations on the device in a secure manner. Keywords: Internet of Things, Security, Provisioning, Authentication, Authorization. 1 Introduction One large problem in open networks is how to provide a high level of data security in the network. In closed networks of high value participants, like PCs with complex operating systems, system operators can provide security by using directory services that provide identity and privilege information to each participant in the network. But in open networks, containing small resource constrained devices, such solutions become impractical. An alternative to using a directory service in open networks has been to let each server (or service) handle authentication and authorization itself. This might work for stand-alone web servers and web applications, where rich user interfaces are available. But small resource constrained devices often have very limited human user interfaces, sometimes perhaps only a small button or a LED, if even that. Performing authentication and authorization on the device itself becomes both a complex and impractical task. Furthermore, performing authentication and authorization on the device itself, makes it difficult to reuse and propagate a user identity and privileges in a network of multiple devices, and makes distributed operations very difficult to perform in a secure manner. To avoid the aforementioned complexities of a uniform security model in an open network of resource constrained devices, some solutions go so far, as to assume any participant with access to the network is trusted to perform the operations it wants to do. Focus is given to the system operator to provide security for the network and only Security in Internet of Things using Delegation of Trust to a Provisioning Server, p. 1, 2014-06-04. Clayster Laboratorios Chile S.A 2014

allow access to the network to participants that are not malicious. This model may work very well in closed networks and back-end solutions, where full control of participants can be guaranteed, but for public open networks, where new participants can participate easily, such a security model quickly becomes impractical for the system operator. This paper proposes an architecture that allows resource constrained devices to delegate trust to a trusted third party, a Provisioning Server, which helps devices to decide which users, devices or services are authorized to perform what operations on the device. It also describes a solution that allows this to be performed over the public Internet using only existing, proven, open and standardized protocols and openly available extensions for maximum interoperability and scalability, and where components would be interchangeable. 2 Problem Description The problem being solved by the proposal is the following: In a public network (the Internet), how do you create user identities that are difficult to falsify for participants in the network, enforce secure user authentication, then provide authorization of who can communicate with whom, and finally when communication links are available, what operations can be performed on which device, by what user or through which service? The solution must support distributed operations and identity propagation. Furthermore, the solution must not use proprietary, but open, methods, allowing any manufacturer to share the same infrastructure if desired, promote interoperability and making sure end-users (or interested parties) can validate that used communication patterns are secure. At the same time, the solution must be simple to implement both by developers and network architects. Example: Consider a PLC with 24 outputs installed in the basement of a building with 10 apartments. How do you assure only users in the 10 apartments are allowed access to the PLC, and at the same time assure that each apartment is only allowed to read and configure the status of two distinct outputs each, while at the same time all 10 apartments can read and control the remaining four shared outputs? This, regardless of what service is used to read or control the PLC. Example: Consider an electricity meter installed in your apartment or house. Both the billing department in the Utility Company and the Energy Savings Company that helps you optimize your energy must have access to the electricity meter. But how do you assure the Utility Company is only allowed access to current and historical accumulated energy values, while the Energy Savings Company is allowed access to momentary power, so it can show you your current consumption? Since the momentary power can be used to detect if somebody is home, it might be a privacy issue who gets access to that value. Example: Competitors are forced to coexist and contractually interchange information between devices in a common network. This means competitors have access to each other s devices. How do you make sure only access to certain registers is given to the competitors, while private information is maintained confidentially?

3 Conceptual Architecture A Thing connects to the network by connecting to a Message Broker. The Message Broker makes sure the Thing is authenticated and provides the Thing with an Identity, which is unique within the Domain of the Message Broker. Message Brokers are then federated into a larger network, each Message Broker defined by its own domain. Communication between Message Brokers is encrypted, and Message Broker domains are validated using Domain Certificates. The Network Identity of the Thing in the federated network is the combination of the local identity on the Message Broker to which it connects, and the Domain Name of the Message Broker itself. Messaging between Things connected to different Message Brokers in the federated network is accomplished by simple message forwarding between the Brokers in the network. The Message Broker maintains a Roster of approved Friends for each Identity on the Message Broker. A Thing is only authorized to send messages to another if the other Thing has a defined Friendship. For Internet of Things, messages are then broken down into the following simple Operations that are well understood by participants in the network: Friendship request, Readout Request and Control Request. Things delegating trust to a Provisioning Server can ask the corresponding questions to the Provisioning Server, to know if the corresponding operations are allowed or not: Can be Friend? Can Read? 1 Can Control? Services in the network can also ask the Provisioning Server Has Privilege? For each question made to the Provisioning Server, the server can respond either by approving the request, denying the request or limiting the request, based on the Credentials of the request itself. Credentials can be both Network Identities, but also Tokens, issued by the Provisioning Server. The architecture allows for multiple Tokens to be used as credentials of a request, and the Provisioning Server can determine which credentials to use as a base for the response. When a response from the Provisioning Server has been received, the Thing can in turn respond correspondingly to the original request made to it. Apart from Network Identities provided to participants in the network, the architecture also provides a mechanism of providing X.509 Certificates based Identities for actors in the network not directly connected to the network, such as Users, Services and Devices. The corresponding entity provides the Public Part of the certificate to the Provisioning Server and the server returns a Token. This token is sufficiently random to be very difficult to guess, but as a string simple enough so that it can be easily propagated across the network. When an operation is performed and a token is provided as credentials, as tokens are not part of the underlying network authentication scheme, the Provisioning Server may pose a Challenge to the sender. This Challenge 1 Note that the Can Read? question to the Provisioning Server is not necessarily a consequence of a previous Read Request made by somebody. It can also be a result of the Thing itself wanting to send an asynchronous event to somebody or use the publish/subscribe pattern to publish information, etc., to make sure the recipients are entitled to receive the information that is about to be sent, and what information the recipients are entitled to.

can in turn be propagated back to the originator of the request. Only the holder of the Private Part of the Certificate can respond accurately on the challenge. In this way, actors in the network can make sure nobody without the correct credentials assumes the identity. To avoid making the Provisioning Server into a bottleneck in the network, Things are required to remember responses to questions posed to the Provisioning Server in a Cache. The size of this Cache and time to store items in the Cache is implementation specific, within certain limits. When changes concerning rules for a Thing are made on a Provisioning Server, the Provisioning Server can ask the Thing to simply clear the cache, as a simple way to make sure updated rules are propagated in the network in a simple way, and avoiding the complexities of maintaining an updated cache using incremental rule changes in a synchronized manner. Since rules for a Thing are not expected to be updated often during normal operation of a Thing, this is not considered to affect network load with any significant order of complexity. The Provisioning Server can also be proactive and Recommend Friendships to Things. In this way, it can connect things and indirectly create new relationships. 4 Choice of Protocol For the solution presented in this paper, XMPP [1] [2] [3] has been chosen as the transport protocol for communication in Internet of Things. Apart from being an open, flexible and extensible protocol [4] it also supports most commonly used communication patterns necessary for Internet of Things, such as request/response, asynchronous messaging and publish/subscribe 2 patterns. XMPP is based on Message Brokers to solve the security issues concerning user identities, authentication, federation, friendship relationships, and message authorization, as discussed above. It can also be used in resource constrained devices [5] [6] and supports resource constrained networks [7]. The operations discussed in this paper are defined in open extensions to XMPP: Sensor data readout is defined in XEP-0323 [8] and control of actuators in XEP-0325 [9]. XEP-0324 [10] provides an extension describing in detail the protocol used to communicate with the Provisioning Server for delegation of trust, and includes details on how to retrieve tokens, respond to challenges, ask for authorization to perform operations, etc. Other benefits of using XMPP for IoT applications include: possibility to bridge between different protocols using XEP-0326 [11], extensions of Semantic Web technologies onto XMPP networks [12] [13], secure in-band registration of new accounts using XEP-0077 [14] and XEP-0348 [15], and control the entire life cycle of Things 2 In XMPP, in comparison to MQTT, the publish/subscribe pattern allows owners of nodes (topics) to control who can subscribe to them, etc. In MQTT, a publisher cannot control who receives the information. Nor can a receiver of information make sure that the information comes from the pretended publisher, unless an additional layer of end-to-end encryption or content signatures are added.

using XEP-0347 [16], which includes production, installation, self-configuration, discovery, ownership, search, disowning and decommissioning of Things. Other available transport protocols lack one or the other of several important features with which XMPP helps IoT developers, whether it is unique authenticated identities that are propagated in a federated network, in-band registration in a secure way of new identities, authorization of messages, or specific communication patterns, etc. A comparison between XMPP and MQTT can be found in [17]. 5 XEP-0324 Internet of Things - Provisioning The entire protocol for communicating with a Provisioning Server is laid out in detail in XEP-0324 [10], to encourage implementation and interoperability between different manufacturers. This document describes how to delegate trust, server components vs. client-based provisioning servers, certificates, tokens, challenges, propagation of tokens, friendships, accepting/rejecting/limiting device read-outs, accepting/rejecting/limiting device control operations, cache management, services, users, privileges, determining support, multiple provisioning servers, security considerations, etc. 6 Existing Provisioning Server A Provisioning Server is available at: provisioning.thingk.me (XMPP Server at thingk.me) The Provisioning Server also hosts a Thing Registry, where Things and Owners can be securely matched according to methods defined in [16]. The URL of the provisioning web interface is: http://thingk.me/ Both the Thing Registry as well as the Provisioning Server can be duplicated and hosted on small plug computers for local use, on PCs, servers or be clustered in the cloud. It is important to note that Thing Registries and Provisioning Servers are two different inventions that can either coexist or work separately of each other. 7 Reactive vs. Proactive Learning XEP-0324 [10] only specifies how Things communicate with the Provisioning Server to get information of what they can do in different situations. However, it does not specify how the Provisioning Server itself gets the information in the first place. The implementation presented here uses Reactive Learning as opposed to Proactive Learning of rules that govern the network. What does this mean? Instead of forcing

the user to beforehand provide possibly very complex rule information to the server, the server reacts to incoming requests and incrementally builds a knowledge database on how to respond to provisioning questions. This means that if a request is made that the Provisioning Server can respond to based information from previous input, the Provisioning Server responds accordingly. Otherwise, the Provisioning Server always responds in the negative, i.e. telling the requester the operation is not allowed. At the same time a simple atomic event is shown or sent to the owner (or operator) of the Thing that a new event has occurred and asks for guidance on how to respond to similar questions in the future. As owners respond to these simple atomic questions, the Provisioning Server incrementally updates the set of rules for the corresponding Things. This allows users to be able to configure otherwise complex networks without having advanced knowledge about the subject. An example of such an event can be seen in [18]. 8 Novel features The proposed architecture is the only IoT architecture publicly available, known to the author, which allows full authorization of Internet of Things operations across a federated network, distributed operation and configuration, including propagation of credentials to sub-operations across the network. It is designed for resource constrained devices and only uses publicly available standardized and openly extended protocols to promote interoperability that can be easily implemented by developers and used by IT architects and operators. The architecture aims for zero-configuration for operators and manufacturers, without compromising security or ease-of-use for end-users. Furthermore, the authorization mechanism does not only include accepting or rejecting of operations, but also include partial acceptance, i.e. limitations, of operations. This extended authorization mechanism is then used to provide for efficient and secure provisioning of services on-top of the network. The architecture is also scalable and can be used both in local environments such as cars, homes, offices, buildings, industry plants, etc., with local Provisioning Servers and local Message Brokers, as well as in global environments, with global Provisioning Servers connected to global Message Brokers. In all cases, there is a logical place where configuration of the network can be done by logical owners of things. The solution also supports multiple Provisioning Servers, allowing different operators to co-exist and together configure a common infrastructure. 9 About the author Clayster is a company with origin in Scandinavia, founded by Rikard Strid and Peter Waher. Clayster is dedicated to the promotion of Internet of Things technology and development of Internet of Things applications. Clayster also provides an IoT platform for rapid application development. Founder Rikard Strid currently lives in New York, USA, and apart from pro-

moting Internet of Things technology, is also a Cisco Champion. Co-founder, and author of this proposal, Peter Waher currently lives and works in Chile where he is CEO of Clayster Laboratorios Chile S.A., a subsidiary to Clayster that provides development expertise to partner companies and promotes Internet of Things technology to research institutions. Originally a mathematician, commercial pilot and computer games developer, he has worked twenty years with computer and device communication, including low-level development in assembler for resource constrained devices to high-level system design and architecture. He s currently participant in various standardization efforts within IEEE, IEC, ISO and XSF, working on standards for the Internet of Things. His work with Smart Applications for the Internet of Things and the development of the IP-TV application Energy Saving through Smart Applications won the Urban Living Labs global showcase award in category Cultural and Societal Participation and Collaboration Tools. Rikard Strid can be found on LinkedIn: http://linkedin.com/in/rikardstrid/ Peter Waher can be found on LinkedIn: http://linkedin.com/in/peterwaher/. 10 Acknowledgements Thanks to Dr. Karin Forsell for all valuable feedback. 11 References [1] P. Saint-André, "RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core," [Online]. Available: http://xmpp.org/rfcs/rfc6120.html. [2] P. Saint-André, "RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence," [Online]. Available: http://xmpp.org/rfcs/rfc6121.html. [3] P. Saint-André, "RFC 6122: Extensible Messaging and Presence Protocol (XMPP): Address Format," [Online]. Available: http://xmpp.org/rfcs/rfc6122.html. [4] xmpp.org, "XMPP Technology Overview," [Online]. Available: http://xmpp.org/about-xmpp/technology-overview/. [Accessed 29 11 2013]. [5] R. Klauck and M. Kirsche, "Chatty Things Making the Internet of Things Readily Usable for the Masses with XMPP," 2012. [Online]. Available: https://www-rnks.informatik.tu- cottbus.de/content/unrestricted/staff/mk/publications/collaboratecom_2012- Klauck_Kirsche.pdf. [6] M. Krische and R. Klauck, "Unify to Bridge Gaps: Bringing XMPP into the Internet of Things," 2012. [Online]. Available: https://www-rnks.informatik.tu- cottbus.de/content/unrestricted/staff/mk/publications/percom_2012-wip- Kirsche_Klauck.pdf. [7] P. Waher and Y. DOI, "XEP-0322: Efficient XML Interchange (EXI) Format,"

2013. [Online]. Available: http://xmpp.org/extensions/xep-0322.html. [8] P. Waher, "XEP-0323: Internet of Things Sensor Data," 2013. [Online]. Available: http://xmpp.org/extensions/xep-0323.html. [9] P. Waher, "XEP-0325: Internet of Things - Control," 06 05 2013. [Online]. Available: http://xmpp.org/extensions/xep-0325.html. [10] P. Waher, "XEP-0324: Internet of Things - Provisioning," 2013. [Online]. Available: http://xmpp.org/extensions/xep-0324.html. [11] P. Waher, "XEP-0326: Internet of Things - Concentrators," 06 05 2013. [Online]. Available: http://xmpp.org/extensions/xep-0326.html. [12] P. Waher, "XEP-0332: HTTP over XMPP transport," 11 07 2013. [Online]. Available: http://xmpp.org/extensions/xep-0332.html. [13] P. Waher, "Extending the Semantic Web to Peer-to-Peer-Like Sensor Networks Based on XMPP". [14] P. Saint-Andre, "XEP-0077: In-Band Registration," 25 01 2012. [Online]. Available: http://xmpp.org/extensions/xep-0077.html. [15] P. Waher, "XEP-0348: Signing Forms," 28 05 2014. [Online]. Available: http://xmpp.org/extensions/xep-0348.html. [16] P. Waher and R. Klauck, "XEP-0347: Internet of Things - Discovery," 10 04 2014. [Online]. Available: http://xmpp.org/extensions/xep-0347.html. [Accessed 05 05 2014]. [17] P. Waher, "Bridging MQTT & XMPP Internet of Things networks," 2013. [18] P. Waher, "Simple example of device readout request event in Clayster Provisioning Server," [Online]. Available: http://twitpic.com/e37ptt/full. [Accessed 30 05 2014].