
Security and Privacy of Using AllJoyn IoT Framework at Home and Beyond Ondrej Tomanek, Lukas Kencl Dept. of Telecommunications Engineering Faculty of Electrical Engineering Czech Technical University in Prague Email: fondrej.tomanek, lukas.kenclg [at] fel.cvut.cz Abstract—AllJoyn is one of the emerging standards for the critical environments. Especially in context of threats arising upcoming revolution known as Internet of Things. Within a from the IoT-shaped world. couple of years, many devices and appliances in every home In this paper, we analyze AllJoyn (as of its late-2015 and are expected to be interconnected, and connected to the global network, using this standard defined by the AllSeen Alliance. In early-2016 releases) and its feasibility to deploy in both small this work, we first review the current status and architecture of and large scale (see Fig. 1). The rest of this paper is organized the AllJoyn open standard, with special focus on its security as follows: x II presents the State of the art. x II also describes aspects. Then, we discuss the security and privacy of the AllJoyn, its architecture and a degree of security it offers. imminent deployment of AllJoyn within homes, buildings and x III discusses risks of deploying AllJoyn: system takeover urban infrastructures across the globe, documenting the need for strong consideration of remedies to the listed vulnerabilities. threat; usage and related difficulties; framework limitations and privacy concerns. We conclude and discuss implications Keywords—AllJoyn, AllSeen Alliance, Security, Internet of in x IV. Things, Intelligent buildings II. STATE OF THE ART I. INTRODUCTION IoT necessitates a novel approach to security as the number of connected devices is up by an order of magnitude, they are Related to the ever-decreasing cost of hardware and con- resource-constrained and impose diverse traffic patterns. The nectivity, the connected-device proliferation passed the point study [5] summarizes open security issues in IoT research, where Internet of Things (IoT) becomes reality. The number such as privacy, integrity and authentication using limited of connected use cases and application areas appears to be resources. Unless these are addressed thoroughly and in a infinite. This proliferation also brings all sorts of problems, timely manner, devices remain at a risk of compromise, which including connectivity, interoperability and security. in turn negatively impacts their owners, surroundings, vendors, A number of solutions are emerging to comprehensively service providers and manufacturers. In fact a number of address these, be it AllSeen Alliance’s AllJoyn [1], Open high-profile flaws has already been discovered, mostly inside Connectivity Foundation’s IoTivity [2], Google Weave [3], the automotive industry [6], [7]. Part of the problem is that Apple HomeKit [4] or various initiatives of IETF, FP7 or the vendors are not properly incentivized to make security a European Commision. AllJoyn and IoTivity are among the part of the whole lifecycle of the product [8]. Another major open standards that enjoy a lot of attention, mainly from orig- reason is a lack of security understanding of all stakeholders inal equipment manufacturers (OEMs). Despite their common - something the initiatives such as The IEEE Cybersecurity goals, standards compete to some extent (as observed from Initiative (CYBSI) [9] aim to tackle. IP policies) and a firm often becomes a member of multiple bodies, waiting to see how things turn out. A. Related Work As standards mature, the initial small-scale deployments Up until recently, proprietary closed ecosystems were driv- are soon to be followed by intelligent buildings and smart ing IoT and security therein. Security, if any, could have only cities. These large-scale environments often uncover a whole been evaluated via black-box testing or reverse-engineering. new host of potential problems and make existing ones worse, With the need for interoperability, semi-open and open ecosys- putting a real pressure on standards. Among the major prob- tems emerged, providing an open specifications with reviews, lems are security and privacy. but also a higher exposure to threats. AllSeen Alliance currently has over 250 members, has a The studies [10] and [11] provide general IoT-device secure- certification system, is shipping production code and has more design guidelines. Transport security of AllJoyn can be di- than 200M AllJoyn-enabled products in the market. Having rectly compared to Transport Layer Security (TLS) [12]. In both merits and drawbacks of an open-source project, AllJoyn contrast to AllJoyn, TLS offers negotiated ciphersuite, rich has to be thoroughly evaluated before deployment in large and crypto options, well-defined extension mechanisms and has 978-1-4673-8473-5/16/$31.00 c 2016 IEEE been highly scrutinized [13]. AllJoyn keystore by default lacks strong protections, as these are platform-specific. The goal for vendors should always be to have a Trusted Platform Module Embedded Embedded Device Device (TPM)-based [14] industry-grade keystore, as implemented for Smartphone instance in mobile devices [15]. App App B. AllJoyn App The AllJoyn framework is an open-source software sys- tem that provides an environment for distributed applications Router IoT Hub (apps) running across different device classes [17]. It en- ables ad hoc, proximity based, peer-to-peer, bearer agnostic Router App networking between devices and applications. AllJoyn re- implements the wire protocol set forth by the D-Bus speci- App Router fication [18] and extends the D-Bus wire protocol to support App distributed devices. To enable Cloud connectivity, remoting AllJoyn devices, message filtering middleware, bridging iso- Fig. 2. AllJoyn Topology. AllJoyn router and application nodes can be hosted lated AllJoyn networks and proxying non-AllJoyn networks, on or even bundled in a single device. Application nodes need a connection the AllSeen-provided Gateway Agent [19] and Device System to the router node for sending messages onto network. Bridge [20] applications exist to be deployed on strategic devices such as IoT hubs. AllJoyn network topology consists of application and routing nodes, sometimes bundled in a C. AllJoyn Security single device (see Fig. 2). The core of the framework comes in At its core, AllJoyn provides mechanisms for authentication, Thin and Standard versions, where the former is designed for authorization, confidentiality and integrity [13]. Inside the resource-constrained devices and requires an external router to application code, interfaces can be annotated as secure and forward messages to other devices. proper callbacks for providing and verifying credentials imple- Applications provide interfaces on a distributed bus con- mented. The connection can also be secured explicitly via API. nected to a router. An interface defines a set of methods Applications decide whether key exchanges are anonymous (invoked by either party), signals (emitted by the producer) or authenticated using either a symmetric or an asymmetric and properties (accessed via get or set actions). An interested key. Once authenticated, the application generates a persistent consumer application discovers the provider interfaces and pairwise master secret shared with every authenticated peer creates a point-to-point session with the producer. AllJoyn also application. From master secret it then derives a symmetric supports a more-efficient less-secure multi-point sessions. session key for encrypting messages on a corresponding point- An interface is expected to be a unit of functionality and to-point session. Every application also generates a symmetric security granularity. AllJoyn security consists of two layers, group key used to encrypt signals on a potential future multi- where the lower provides fundamental security mechanisms to point sessions and distributes the group key to every connected be invoked via APIs and the upper (called Security 2.0) adds peer application for decryption. NIST currently expects the semantics and provides for a configurable and manageable crypto suite in AllJoyn to be good at least until 2030 [21], security, decoupling these from the application code. assuming the platform provides enough entropy for either a platform-provided random number generator or the AllJoyn- provided CTR DRBG [22]. All the mechanisms are to be invoked via language bindings. The fixed ciphersuite includes 128-bit AES CCM [23], SHA-256 HMAC [12], ECDSA [24], Wired [25], EC-SPEKE [26], [27] and ECDHE [28] with NIST P-256 connecon Cellular curves. The crypto assets are stored in the encrypted storage, LTE whose protection strength is based on what the platform offers. Gateway As the number of crypto assets can potentially become high, Panel secure devices need to have network buffers and NVRAM box sized appropriately. Optimizations and offload can be achieved AllJoyn by porting the code and thus replacing built-in AllJoyn crypto. Thread Wi-Fi BLE D. AllJoyn Security 2.0 To enable broader adoption and support future development, Mission-cri5cal Powered Baery-powered the late-2015 version of AllJoyn adds a “Security 2.0” business controls sensors sensors layer on top of existing AllJoyn security. Its main contributions Fig. 1. Industrial AllJoyn [16]. The envisioned deployment of AllJoyn in include: a configuration approach for working with security, industrial, building and smart-city networks. ontologies to make security more comprehensive and various Consumer device Producer device
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages6 Page
-
File Size-