Securing the Life Cycle of Things in the Internet of Things using Thing Registries

Transcription

1 Securing the Life Cycle of Things in the Internet of Things using Thing Registries Architecture overview Peter Waher Clayster Laboratorios Chile S.A, Blanco 1623, of. 1402, Valparaíso, Chile Abstract. This paper proposes an architecture and describes an implemented solution that allows secure installation, self-configuration and discovery of massive amounts of Things on the Internet (Internet of Things), aiming for zero-configuration where possible and at the same time minimizing risks of malicious users hijacking devices, using existing open and standardized protocols and extensions. It also aims for a simple solution that is simple to implement, both by developers and network architects. Keywords: Internet of Things, Security, Installation, Configuration, Discovery. 1 Introduction Most ideas and solutions proposed for the Internet of Things concern mockups, prototypes of devices or proof of concept system designs, configured manually to provide conceptual ideas of what the Internet of Things could become. The focus is often placed on message transport and service functionality, and seldom on security and mass-distribution of a finished product that can be sold off the shelf. This paper proposes an architecture that would allow a manufacturer to manufacture Things, that can be sold at retail stores, Things that detect network topology and auto-configure themselves accordingly once installed, and then use concepts presented herein to in a secure manner allow its true owner to connect to the Thing and take control of it, while at the same time minimizing the risk of malicious users being able to access the Thing and hijack it. All this is then implemented in a solution that allows this to be performed over the public Internet using only existing, proven, open and standardized protocols and 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 safely connect Things to their owners, if knowledge about how to reach them is not available to either one of them? Here, safely means without Securing the Life Cycle of Things in the Internet of Things using Thing Registries, p. 1, Clayster Laboratorios Chile S.A 2014

2 risk (or minimizing the risk) of third parties hijacking Things by pretending to be their lawful owners. Furthermore, the solution must not use proprietary, but open, methods, allowing any manufacturer to share the same infrastructure if desired 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, and incur as little costs as possible in the production environment. The solution aims for providing a solution for mass-production of massive amounts of inexpensive products, in a secure manner and requiring a minimum of manual intervention. 3 Conceptual Architecture A Thing bought off the shelf in a retail store, is assumed to have no pre-knowledge of what network topology it will be installed in, or who its owner will be. All it knows is meta-data about itself, chosen by the manufacturer, and methods once installed to connect to the network and necessary infrastructure components, like message brokers, and to create a user identity (or Thing identity) to be able to participate in network communication securely. Once a connection to the network has been made and an identity created, it registers itself with a Thing Registry by sending its metainformation to the registry, using the newly created identity on the network. The Thing Registry maintains a private list of meta-data and Thing identity pairs. The owner, once having installed the Thing physically, resulting in its registration in the Thing Registry, then claims ownership of the Thing, by sending the same metadata to the Thing Registry. The Thing Registry in turn, once having matched a claim from a supposed owner with the corresponding registration from the Thing, informs the owner the identity of the Thing, while at the same time informing the Thing the identity of the owner. The owner can also choose to allow the Thing to become public, meaning the existence of the Thing, its identity and meta-data becomes publicly available and searchable. The owner can also choose to keep the Thing private, meaning the Thing Registry removes the corresponding entry from its database since it has now fulfilled its purpose of matching the Thing identity with its Owner identity by using shared knowledge about the Thing. The above architecture presupposes three Things: First, that having knowledge of the meta-data about the Thing implies ownership of the Thing. Secondly, that there is a method whereby this meta-data is easily transferred without errors from the Thing to the Owner. Thirdly, that the meta-data cannot be easily deduced or guessed by third parties trying to get access to the Thing. The implemented solution described in the following sections demonstrates how this can be solved in a simple way.

3 4 Implemented Solution 4.1 Choice of Protocol For our solution, we ve chosen XMPP [1] [2] [3] 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 patterns. It can be used in resource constrained devices [5] [6], support resource constrained networks [7] and work is being done to formalize open interoperable extensions for the Internet of Things [8] [9], protocol bridging [10] and provisioning of services in IoT networks [11]. Furthermore, extensions exist allowing the extension of Semantic Web technologies onto XMPP networks [12] [13]. Important for this solution is the use of Message Brokers to authenticate user identities in the network, and also the support for In-band registration of new accounts available in XMPP [14]. Even though the original method of in-band registration is not safe for use in public servers by Things, there is an extension available that corrects these flaws so that in-band registration of new accounts can be made by both humans and machines in open environments is a secure way [15]. Other available transport protocols, such as MQTT, AMQP, etc., do not support inband registration of new accounts. New accounts have to be either created either outof-band in a proprietary fashion or manually by an operator. Alternatively, the broker has to be configured in a way that allows everybody to connect to the network and pretend to be anybody they like [16]. Other methods, such as HTTP and CoAP, do not use message brokers to authenticate Thing identities, which make trust a problem. To minimize the risk of Things being hijacked, you need a transport protocol that helps Things make sure who the senders of packets are. Placing the burden of authenticating each entity wanting to communicate with the Thing on the Thing itself, places an unreasonable burden on the Thing, resulting in situations where manufacturers will simply ignore it, or implementations to be faulty, wanting or proprietary, resulting in an overall network solution that would be unsecure if anybody would be given access to the network or if the solution is comprised of products and services from different manufacturers. Since we aim at including resource constrained Things, and having the entire lifecycle of the Things supported by one protocol, XMPP becomes the best possible candidate. The message structure used is available as an open extension to XMPP [17]. 4.2 Discovering Network Topology After installation of a Thing, when starting it for the first time, it needs to detect critical network components in order to be able to register itself. The first step is to connect to the Internet. This is standard procedure and will not be discussed in this document. The second step is to find an XMPP Server in which the Thing can register an account. Apart from using a preconfigured XMPP Server (or list of XMPP Servers),

4 [17] lists three dynamic options: First, by using DHCP options to find the server. Another option is by using Multicast DNS (mdns) and DNS Service Discovery (DNS-SD). Finally, SSDP and UPnP can also be used 1. Once the XMPP Server is found, an account has to be registered with the server. This is done using in-band registration [14] and form signatures [15]. A Form signature is a method whereby the account creation form is signed using external credentials. These credentials correspond to a corresponding account on the XMPP server or corresponding directory, allowing the creation of a certain number of XMPP accounts (JIDs). In this way, it is possible for operators, network architects or manufacturers to maintain control of how many accounts have been created and by whom. It also creates a logical business model between infrastructure operators and device manufacturers. The method also makes in-band registration safe to use on public networks, since robots without valid credentials will not be allowed to create accounts automatically. 4.3 Registering the Thing in the Thing Registry The last step in the installation phase, is to find the Thing Registry and for the Thing to register itself there. The most common method listen in [17] concerns searching through server components registered with the XMPP server to which the Thing is connected. The Thing Registry can be integrated with the XMPP Server as a server component [18], allowing scalable access to network communication without the need to be an integral component of the server itself, and without the requirement to be a friend of each Thing communicating with it. Once the Thing Registry has been found, the Thing registers itself sending its meta-data to the Thing Registry. Example: <iq type='set' from='thing@clayster.com/imc' to='discovery.clayster.com' id='1'> <register xmlns='urn:xmpp:iot:discovery'> <str name='sn' value=' '/> <str name='man' value=' <str name='model' value='imc'/> <num name='v' value='1.2'/> <str name='key' value=' '/> </register> </iq> 1 Work is being performed in the UPnP Forum to define an UPnP service interface for XMPP servers.

5 4.4 Transfer of Meta-Data The key to making installation secure, is to make the meta-data reported by the Thing difficult (in practice impossible) to guess, while at the same time simple to implement and simple to transfer from the Thing to the Owner, so that the Owner can report the same meta-data. As described in [17], Meta-Data consists of a collection of string and numerical tags (name & value pairs). These tags can be easily encoded into a string, as is shown in the following example: IoTDisco;SN: ;MAN: MODEL:IMC;#V:1.2;KEY: This string can then be encoded into a QR-code, for instance by using an open API, like the Google Chart API. Example: chl=iotdisco;sn: ;man: MODEL:IMC;%23V:1.2;KEY: This URL returns a QR-code, as follows: It is assumed that, if the owner has access to the Thing and its package it is also its owner. This means, that the QR-code above, containing the meta-information can be displayed on a sticker on the box of the Thing for instance, or on the display of the Thing itself, if it has a display. This QR-code is then read using a smartphone app in the hands of the owner and sent to the Thing Registry, which matches the claim with any meta-data sent from Things earlier. If a match is found, both the owner and the Thing are informed of this, together with information of each other s identities. Example of an owner claiming a Thing: <iq type='set' from='owner@clayster.com/phone' to='discovery.clayster.com' id='4'> <mine xmlns='urn:xmpp:iot:discovery' public='false'> <str name='sn' value=' '/> <str name='man' value=' <str name='model' value='imc'/> <num name='v' value='1.2'/> <str name='key' value=' '/> </mine> </iq>

6 More information on how owner and Thing get the other s communication identities can be found in [17]. 4.5 Public Things Owners can decide which Things it wants to keep private, and which Things can become public. Public Things are searchable, on all meta-data provided (except the KEY tag), including location. This makes the Thing Registry work as a bulletin board for Things, and can be used by services to find publicly available Things to interact with. Public Things can update their meta-data during their entire life cycle, to make sure meta-data is always up-to-date. Here, public depends on the location of the Thing Registry. A local Thing Registry on a plug computer in your home (or on a gateway/firewall/router) would work as a bulletin board for Things in your home, for instance. For more information about search features and operators, see [17]. 4.6 Existing Thing Registry A Thing Registry that can be used for development and testing is available at: discovery.clayster.cl (XMPP Server at clayster.cl) The Thing Registry also hosts a provisioning server, where claimed Things can be managed according to rules defined in [11]. This allows users to control who can access Things and what they can do with the Things, all through a web interface. Furthermore, the user can read Things in accordance with [8] and configure them in accordance with [9]. Bridging between protocols is also supported in accordance with [10]. The URL of this web interface is: 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. 5 Novel features The proposed architecture is the only IoT architecture publicly available, known to the author, that takes the entire Thing Life Cycle into account, including production, installation, configuration, account creation, connection to owner, runtime, ownership change, decommissioning and deregistration, and that only uses publicly available standardized and openly extended protocols that can be easily implemented by both developers, IT architects and production environments, aiming for zero-configuration

7 where possible, without compromising security. At the same time, it creates a logical business model for Operators in the Internet of Things. Through this model architecture Operators can create a scalable Internet of Things infrastructure that manufacturers and end-users can use that enables the vision of Internet of Things. 6 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 promoting 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: Peter Waher can be found on LinkedIn: References [1] P. Saint-André, "RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core," [Online]. Available: [2] P. Saint-André, "RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence," [Online]. Available: [3] P. Saint-André, "RFC 6122: Extensible Messaging and Presence Protocol (XMPP): Address Format," [Online]. Available: [4] xmpp.org, "XMPP Technology Overview," [Online]. Available: [Accessed ]. [5] R. Klauck and M. Kirsche, "Chatty Things Making the Internet of Things

8 Readily Usable for the Masses with XMPP," [Online]. Available: 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," [Online]. Available: 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," [Online]. Available: [8] P. Waher, "XEP-0323: Internet of Things Sensor Data," [Online]. Available: [9] P. Waher, "XEP-0325: Internet of Things - Control," [Online]. Available: [10] P. Waher, "XEP-0326: Internet of Things - Concentrators," [Online]. Available: [11] P. Waher, "XEP-0324: Internet of Things - Provisioning," [Online]. Available: [12] P. Waher, "XEP-0332: HTTP over XMPP transport," [Online]. Available: [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," [Online]. Available: [15] P. Waher, "XEP-0348: Signing Forms," [Online]. Available: [16] P. Waher, "Bridging MQTT & XMPP Internet of Things networks," [17] P. Waher and R. Klauck, "XEP-0347: Internet of Things - Discovery," [Online]. Available: [Accessed ]. [18] P. Saint-Andre, "XEP-0114: Jabber Component Protocol," [Online]. Available: