10 posts categorized "Internet of Things"

12/12/2014

Intel’s IoT Platform Extends Security Toward Edges

At a press and analyst event in San Francisco on December 9, Intel announced its “IoT Platform” reference model. The model is horizontal in scope, encompassing numerous technologies applicable to everything from edge devices to gateways to the cloud. In addition, it is intended to be a modular approach, such that Intel’s hardware and software components (including those from subsidiaries Wind River and McAfee) can be mixed with those of other vendors. For example, a customer could deploy its preferred gateway devices not limited to those based on Intel’s Moon Island design, while remaining compatible with Intel’s reference model. We won’t attempt to describe the entire Intel IoT Platform in this blog post, but we’ll focus on a couple of security aspects announced. (Readers can find the full Intel press release here.)

  Intel-McAfee Security Execs

Intel executives discuss IoT Platform security: (left to right) Lorie Wigle, VP of IoT Security Solutions; Steve Grobman, Intel Fellow and CTO for Security Platforms and Solutions; and Luis Blando, SVP of Intel Security Group [McAfee].

As part of the latest announcement, McAfee’s ePolicy Orchestrator (ePO) is being extended into IoT gateways. ePO is software for security management, enabling centralized deployment and control of security policies, as well as monitoring of endpoint security status. Previously, ePO was intended for enterprise IT networks, but the announcement means that it can now encompass a much wider range of industrial and commercial IoT networks. In VDC’s opinion, this could help ease integration between IT and OT (operational technology) departments when transitioning standalone OT systems into IoT systems. OT could maintain functional control over the gateways and edge devices, while IT institutes improved access control between the gateways and enterprise network assets.

A second notable security announcement was that Intel Security will now license its Enhanced Privacy Identity (EPID) technology to other silicon vendors. EPID is a form of remote anonymous attestation using asymmetric (public key and private key) cryptography, through which central systems can confirm the integrity and authentication credentials of remote devices, without those devices having to reveal their identities or those of their owners. (One common use for anonymous attestation is digital rights management for content protection.) Anonymous attestation requires security hardware, such as a CPU with a Trusted Platform Module (TPM) or Trusted Execution Environment (TEE), for which Intel of course is a prime supplier.

EPID can create groups of devices, where a single public key can work with multiple private keys, i.e. one assigned to each device within the group. The mathematics behind EPID is complex, but for those interested, we suggest checking out the article, “Enhanced Privacy ID: A Remote Anonymous Attestation Scheme for Hardware Devices,” by Intel’s Ernie Brickell and Jiangtao Li (Intel Technology Journal, Volume 13, Issue 2, 2009, pp. 96-111). The chart below from that article summarizes how EPID differs from other attestation technologies, including Direct Anonymous Attestation (DAA).

  AttestationComparison
Chart source: Intel Technology Journal

Intel has not yet disclosed licensing terms for other chip makers to use EPID, and onerous or expensive terms could limit its acceptance. However, VDC believes that EPID could be applicable to many IoT scenarios where a central system needs to trust remote devices owned or operated by others. This type of function will become increasingly important as interested parties seek to extract shared or publicly provided data from private IoT devices.

Although numerous security technologies from many vendors are taking hold in the IoT, Intel is uniquely positioned in this market by virtue of its presence at both the network/system level (McAfee, Intel Server Systems) and the device level (Intel CPU hardware, Wind River software). Intel says, for example, that its existing McAfee Embedded Control software for application whitelisting is used by about 200 device manufacturers. Intel’s IoT Platform is the latest evidence that the company will remain a force to be reckoned with in IoT security.

11/14/2014

Automotive Privacy Protection Principles Don't Go Far Enough

The Association of Global Automakers and the Alliance of Automobile Manufacturers jointly announced on November 13, 2014 a set of voluntary “Consumer Privacy Protection Principles.” (See the press release here, and download the principles PDF document here.)

The document is written in quasi-legalese, but in essence, it’s a pledge by automakers, beginning with the 2017 model year, to among other things:  ConsumerPrivacyProtectionPrinciples

  • inform consumers about how data collected from their vehicles will be used
  • obtain “affirmative consent” for certain ways that data might be used
  • anonymize aspects of the data under some circumstances

VDC applauds the auto industry for recognizing the importance to consumers of privacy for data collected by electronic and digital technologies, which are growing by leaps and bounds in new vehicles. However, the principles don't go far enough in several respects:

Security – The document states that participating members must “implement reasonable measures to protect Covered Information against loss and unauthorized access or use,” then says that “reasonable measures include standard industry practices.” The word reasonable is too wishy-washy in this context, so those statements in the privacy principles don’t inspire confidence that automakers and their partners will go the extra mile for data security. (Why don't the principles say the members must "implement strong measures" to protect the data?) Without defining any minimum security measures or committing to create or adhere to an ISO standard, it comes across as a nice way of saying, “We’ll make a good effort at security, but don't expect us to guarantee the data won't get breached.” In addition, security issues apply for data within vehicles' internal systems, for data during communications from vehicles to infrastructure, and for the databases where the manufacturers will aggregate and store the data. Security policies should specify minimum requirements for how data will be secured at each of these levels, as well as how authorized third parties with data access will be required to secure the data.

Consent – The document states that automakers need to obtain consent to “a clear, meaningful, and prominent notice disclosing the collection, use, and sharing of Covered Information.” However, the document includes no provision for a vehicle owner to deny such consent or revoke it afterwards. Why would that be important? Because the consent form is likely to be presented to consumers among a stack of numerous papers that they sign in a perfunctory manner when buying a car. In addition, consent ideally would provide vehicle owners with the ability to agree or not to agree to each type of data collected, rather than any blanket statement of consent to collection of all data. We’ll see how this plays out when the first consent forms hit the market.

Data Access – The document says that consumers will have “reasonable means to review and correct Personal Subscriber Information.” Such information may include name, address, telephone number, email address, and even credit card number. It’s fine that automakers will give consumers the right to access the data that they themselves provided in the first place, but what the document misses entirely is the basic principle that consumers should have the right to access data produced by their own vehicles. Although this isn't a data privacy issue, it is a data rights issue that automakers need to address. In VDC’s opinion, vehicle owners should have, for example, the ability to take diagnostic data to an independent mechanic, rather than manufacturers only providing such data to its dealers or third parties that have paid to access it. And vehicle owners should have the ability to access geolocation data generated by their own vehicles. Certain types of data may need to be kept confidential, but the default should be to provide consumers access to data from their own vehicles unless there’s a legitimate safety reason not to make it available to the people whose vehicles generated it.

For further discussion of data rights issues related to the automotive industry and the Internet of Things, see the recent VDC View article entitled, Beyond "Who Owns the Data?" 

10/07/2014

How Significant is ARM’s mbed OS?

For microcontrollers (MCUs) used in embedded devices, intellectual property supplier ARM is the clear market leader. In a recent forecast for VDC Research’s report “The Global Market for Embedded Processors,” ARM-based MCUs accounted for more than half of the unit shipments using non-proprietary architectures in 2013 (see chart).

MCU Shipments by Architecture

The Cortex-M series is the main line of ARM MCUs, and is the most prevalent architecture used in embedded devices for the IoT. So when ARM announced on October 1 at the TechCon convention and trade show that the company would provide a free operating system—the mbed OS—for the M-series, it created considerable buzz in the industry, as well as some consternation and a bit of confusion.

ARM has been using the mbed name since 2005 for “maker”-style development platforms based on Cortex-M series MCUs, along with a large community of developers and an extensive software library. But the new announcement greatly expands the original mbed concept. The mbed name now encompasses not only the new operating system, but also: a cloud connectivity platform (mbed Device Server); a set of development tools (mbed Tools); and an ecosystem of partners (mbed Partners). Effectively, mbed has become a line of both products and services. ARM says that collectively, mbed will “accelerate Internet of Things deployment.” In this blog post, we’ll focus on the mbed operating system.

The embedded industry is already rife with many dozens of operating systems, ranging from bare bones to fully-featured. These include commercially-licensed binaries (closed source), commercially-licensed open source, free open source, as well as proprietary in-house OSs.

For resource-constrained embedded devices, the free open source offerings have been popular but limited in the extent of their development. Generally, commercially-licensed OSs are more professionally designed, thoroughly tested, and robust.

Several aspects of the mbed OS are noteworthy. First, ARM says that its free OS will be commercial grade. By offering it for free, the mbed OS will compete with some of the commercial embedded OSs already on the market. However, in his keynote speech at TechCon, ARM’s CTO Mike Muller emphasized that the mbed OS will not be a real time operating system (RTOS). Many IoT devices require the time-critical determinism of an RTOS, most notably in safety critical applications such as avionics, automotive systems, factory automation, and the like. The lack of real time functions will limit the breadth of applicability for mbed OS, and the extent to which it will compete with many of the commercial OSs on the market.

Second, ARM said its main intention of releasing the OS along with the mbed Device Server was to ease embedded software development to handle the many security concerns and communications protocols used in IoT, as those are often sticking points for developers not previously experienced with connected devices. Zach Shelby, Directory of Technical Marketing for the ARM’s IoT initiatives, noted that even devices running competing commercial OSs will be able to take advantage of mbed Device Server connectivity services. As Shelby described it, ARM isn’t trying to compete with OS vendors, the company is trying to ensure that IoT developers have adequate support to bring products to market in a timely manner.

Third, although ARM did not mention this in its press information Shelby told VDC that much of the mbed OS source code would be made available as open source. He also said that a few specific software components (such as some security modules) would be released only as binaries, i.e. closed source, which is why the company hasn’t been touting the OS as “open source.”

And fourth, ARM’s announcement only described the mbed OS as being for the M-series MCUs, but Shelby told us that partners will be able to adapt the open source code for ARM’s other series of processors. Indeed, at least one hardware vendor on the show floor was demonstrating a working version of the mbed OS on a Cortex A-series microprocessor. However, the higher performance A-series line is often used with more fully featured operating systems (e.g. Linux), and VDC doesn’t consider it to be a major target for the mbed OS.

All-in-all, VDC believes that the mbed OS will be significant for how it should speed up development for new entrants in the IoT. It probably won’t cause a major upheaval in the broad market for commercial embedded OSs, but a few of the OS vendors at the low end of the market are likely to be adversely impacted.

10/02/2014

Notable Demos from ARM TechCon 2014 and JavaOne

Semiconductor intellectual property supplier ARM kicked off its annual TechCon conference and trade show in Santa Clara, CA with expansion of the mbed IoT Device Platform, including a free operating system as well as server side IoT technologies. We describe the mbed OS in more detail in a separate blog post. In this post, we’ll highlight a couple of notable demos from other vendors on the show floor, plus one from Oracle’s concurrent JavaOne conference and trade show in San Francisco. In a literal sign-of-the-times at both events, you couldn’t swing a dead cat without hitting a sign that read, “Internet of Things.”

At ARM TechCon the Cryptography Research division of Rambus showed an interesting demo of differential power analysis (DPA). This is a type of side channel attack based on sensing power consumption and/or emission patterns of a processor during cryptographic operations, with the objective of extracting encryption keys. Prior to seeing this demo, we had thought of DPA as an academic or theoretical exercise that either wouldn't work in the real world or would take so long as to be insignificant. But Rambus showed us exactly how it works, measuring power emissions from a Xilinx chip while it was repeatedly performing AES 128-bit symmetric encryption on short blocks of data, and running statistical analysis on the power readings to uncover the encryption key one byte worth at a time. The entire key was recovered in about two minutes. Because the process is linear with the number of bits, AES 256-bit only would have taken about four minutes. (To break 256-bit encryption by brute force methods is orders of magnitude more difficult than to break 128-bit.) In addition, the company demonstrated a simple power analysis (SPA) side channel attack by handholding a receiver antenna to the back side of an Amazon Kindle tablet (see Picture 1), and directly reading a signal containing the asymmetric key from RSA 2048-bit encryption running in software on the device. No statistical analysis was required, as a viewer could see a graphical form of the signal representing the zeros and ones (Picture 2).

Rambus3

Picture 1: Readng power emissions from a Kindle tablet running encryption software.

Rambus2

Picture 2: Kindle emissions isolated in the frequency band of the encryption key. Narrow distances between the gaps are zeros, and wider double distances between the gaps are ones. The section of the key shown reads as 0011000001.

Needless to say, we were impressed with how easily these attacks were executed, which of course was the entire point of the demos. Rambus offers side channel attack countermeasures in the form of hardware cores and software libraries, and the demos also showed how such countermeasures confound the measurements and analysis.

Green Hills Software teamed up with Freescale to demonstrate a retail POS simulation of a RAM scraper malware technique similar to the type implicated in the Target data breach, as well as a solution using INTEGRITY hypervisor to negate the malware. The protection method keeps the credit card data encrypted in a secured application space before it gets to the normal execution area, then sends the data via secure channel to the payment processor server. Only a one-time token is passed to the normal execution area of the POS system. When that token is submitted to the payment processor, the funds are approved, without the credit card data ever existing in the normal execution area, and thus rendering RAM scraping irrelevant for theft of the card data. This type of tokenization has been done before in the payment card industry (PCI), and we expect the Target data breach will increase its uptake.

And at the JavaOne event, Oracle and the French software firm Oberthur Technologies demonstrated an Android device with a Java Virtual Machine running within an ARM TrustZone trusted execution environment (TEE). Oberthur’s software runs on the server side of an Internet connection, and enables specially designed Java apps to be securely installed into the device also using a tokenization method. This is the only solution we’ve seen to date that enables applications to be remotely installed into a TEE. Although the demo was run on an Android phone, we see the potential for its use in many other types of IoT devices.

08/07/2014

IoT Lessons from the Russian CyberVor Hacking

Widely reported during the first week of August was the revelation that a group of Russian hackers known as CyberVor had amassed a database of 1.2 billion usernames and passwords, as well as more than 500 million email addresses. The New York Times originally broke the story, based on findings from the firm Hold Security. Unlike the Target retail data breach of late 2013 and the more recent eBay breach, CyberVor’s loot is not the result of one or two large breaches, but rather a large number of breaches of all sizes. Hold Security says that the data came from 420,000 websites, ranging from large household-name dotcoms down to small sites. Most of the sites were breached using SQL injection techniques through malware infecting the computers of unwitting legitimate users.

Breaches of major websites or retailers tend to be highly concentrated, narrowly focused efforts, whereas the database collected by CyberVor appears to be the result of casting a very wide (bot)net, trawling the world wide web for anything the group could catch.

What lessons can the CyberVor revelation teach us (or reinforce) about the Internet of Things?

Lesson #1: No IoT site (either physical or virtual) is too small to be attacked. Many users are tempted to think, “Why would anyone bother to hack my little IoT network?” The answer is, “Because they can.”

Lesson #2: Even data that has little or no value to hackers on its own may have value when aggregated.  If you think your data is worthless to others, you’re probably wrong. Big data is comprised of a whole lot of little data.

Lesson #3: Authorized users or devices are not necessarily safe just because they are authorized. Follow the principle of least privilege, in which users or devices only have access to the minimum amount of data and system resources necessary to perform their functions.

Lesson #4: Monitor your networks for atypical or unexpected movements of data. This is challenging in practice, because valid usage occasionally may not follow past patterns. Nevertheless, at a minimum the system should have a way to throw up a red flag if a user or device is attempting to copy large portions of a database.

Lesson #5: Don’t neglect the basics. SQL injection attacks as well as buffer overflows and cross-site scripting are common and easily preventable. Most software code analysis tools can check for vulnerabilities to such attacks early in the development process.

Lesson #6: Conduct independent penetration tests on your devices and networks. If you think that your own engineers already have covered every possible attack vector, you’re probably wrong. You need outside eyeballs incentivized to find flaws without concern about stepping on coworkers’ toes.

And lastly, Lesson #7: At the risk of stating the obvious, encrypt your data. Any database that is accessible either directly or indirectly from the Internet is worth encrypting. Passwords in particular are keys to the kingdom. Encrypt them with salted hash techniques and strong algorithms. There is never a valid reason to store passwords in plain text.

If the websites breached by CyberVor already had learned these lessons, the hack wouldn’t even have been newsworthy.

For more insights into IoT security issues, check out VDC’s research program on Security & the Internet of Things.

07/21/2014

VDC Embedded Jama Software Webinar

How to Understand Requirements Management to Develop and Deliver Faster

For Embedded Systems Developers, Time to Market is Critical. Learn the No. 1 Strategy to Develop and Deliver Faster.

During this free webinar on Wednesday, July 23 at 1:00pm ET / 10:00am PT, VDC Research analyst André Girard and Jama Software co-founder Derwyn Harris will present on the growing necessity for requirements management (RM) tools in the face of today’s increasingly complex code bases, distributed development teams, and stricter budgets.

OEMs are facing constant pressure for innovation even with tight budgets, and they are dedicating more of their resources towards software development. Despite the importance of well-written requirements in the software development lifecycle, usage rates of RM tools are still dangerously low, with only 23% of embedded engineers polled by VDC in 2014 indicating they were using a formal RM solution on their current project. To meet demands for an accelerated pace of software content creation, developers will need to better utilize RM tools to monitor and manage the development lifecycle from beginning to end.

This webinar will explore: 

  • How has the software development process changed? 
  • What challenges are OEMs facing today? 
  • How do RM tools help deal with these challenges? 
  • How can RM tools save time and money for OEMs?

Tune in to this webinar to learn the answer to these questions and more. Those who register for this webinar will also receive a free copy of VDC Research’s report, “Pinching Pennies on Requirements Management is Too Costly”, by André Girard.

Click here to register for the webinar. To learn more about the research and products offered by VDC Research’s Embedded Software & Tools practice, click here.

 

Patrick McGrath

Research Associate, VDC Research

06/18/2014

IoT Necessitates Changes in Both People and Technology

The requirements of the devices composing the Internet of Things are changing rapidly. The embedded market no longer consists of dedicated-purpose devices that may or may not be connected. Engineering organizations and deploying enterprises must now design scalable system topologies that can integrate new devices and adapt to the IoT’s evolution. While these next-generation systems are required to facilitate downstream device/node management as well as efficient upstream data transfer and analytics, they must also do so dynamically, allowing for more intelligence and flexibility in node role and workloads within sub-network architectures.

This recognition of a need for change in legacy technologies can already be seen in the shift in programming languages used by embedded engineers. In the past five years, the percentage of engineers using Java in the embedded market has more than doubled. Embedded industry stalwarts such as C will certainly maintain a substantial footprint going forward given the existing software assets and expertise at OEMs, but the results confirm that the market is rapidly looking to new and/or multi-language development to satisfy the requirements of next-generation projects.

Picture1

IoT Skill Set Gap Exacerbated by Existing Embedded Resource Gap

The existing embedded engineering resources unfortunately cannot keep pace with the IoT’s time-to-market and content creation requirements. Already this community has been struggling to meet the needs of pre-IoT development projects. Now, the industry is faced with a dynamic in which not only does it need more efficiency, but the existing population of embedded engineers also cannot scale organically to meet the new software content creation requirements. Today, there are just over 1 million embedded engineers globally, with only 35% of that community holding software engineering-specific primary roles. In order to adapt to the new IoT development demands and respond to this dearth of traditionally skilled resources, OEMs must look to new labor pools.

The global Java community, which is estimated to consist of approximately 9 million developers, offers an opportunity to draw upon an increasingly relevant labor and expertise pool. The value of traditional embedded engineering skill sets has already been partially devalued due to IoT system evolution. Now, knowledge of connectivity stacks and UI development often must be placed at a premium over skills such as footprint optimization. Furthermore, technology like Java’s virtual machines create an abstraction layer that can reduce hardware dependencies and the subsequent rework and optimization that would have previously required more traditional embedded firmware engineers. Despite the already rapid adoption of Java (by embedded standards), we believe that the impending blurring of the distinction between embedded and IT Java developers will reinforce the technology’s adoption and relevance going forward. The wide access to the existing ecosystem of Java tools and third-party software, combined with a growing embedded partner ecosystem spanning semiconductor/IP companies, tool, and hardware/system manufacturers will no doubt further reduce switching costs and any lingering reservations held within many embedded industries.

We will be exploring the business and technical impact of the IoT in a webcast tomorrow with Oracle:

Date: Thursday, June 19, 2014 

Time: 9:30 AM PDT, 12:30 PM EDT, 17:30 GMT

Join this webcast to learn about:

  • Driving both revenue opportunities and operational efficiencies for the IoT value chain
  • Leveraging Java to make devices more secure
  • How Java can help overcome resource gaps around intelligent connected devices
  • Suggestions on how to better manage fragmentation in embedded devices

Register here:

http://bit.ly/1oOuuS9

06/16/2014

PTC Acquires Atego, Broadens ALM Support for Product Development

What happened?

PTC (NASDAQ: PTC) announced today it has entered into a definitive agreement to acquire Atego, a leading developer of model-based systems and software engineering applications based in the UK, for $50 million in cash. The transaction is expected to be completed in PTC’s fiscal fourth-quarter 2014, which begins in July. According to PTC’s press release, Atego had approximately $20 million in revenue over the course of the past 12 months, and the company expects it will achieve approximately $5 million in revenue from Atego in PTC’s fiscal fourth-quarter 2014.

VDC’s View

Several recent acquisitions by PTC have targeted services lifecycle management (SLM). The combination of PTC’s SLM portfolio and their IOT capabilities through ThingsWorx provides an impressive depth and breadth of solutions for extending customer relationships post-deployment.

This newest addition of modeling tools from Atego strengthens PTC’s portfolio of product lifecycle management and application lifecycle management solutions and helps reinforce a systems engineering focus. Atego’s Model-Based Systems Engineering solutions connects requirements engineering, architecture modeling, physical product definition, and system verification functions.

Today’s smart, connected products depend on the tight integration of sophisticated components from multiple engineering domains, raising the value proposition of increased cross-discipline coordination and communication. The combination of Artisan Studio from Atego with their existing tooling portfolio enables PTC to offer solutions that help their customers increase efficiency and product standardization in embedded industries where increasingly connected products are created from systems of complex mechanical, electrical, and software systems.

Stay tuned here for further insight in the coming days.

VDC will be exploring these and other trends in greater depth within our upcoming Software & System Lifecycle Management Tools research program.  Please contact us for additional information.

 

By Patrick McGrath, (Research Assistant, M2M & Embedded Technology) and Andre' Girard (Senior Analysis, M2M & Embedded Software)

04/23/2014

Exploiting the Exploit: The Marketing of Heartbleed

No doubt anyone reading this post is already aware of the Heartbleed bug affecting OpenSSL implementations of the TLS Internet security protocol. Heartbleed has received massive press coverage –deservedly so given its potential implications for a significant portion of web sites and Internet-connected devices. We won’t belabor the technical details of the bug, which are summarized nicely at Heartbleed.com. What we will discuss is how Heartbleed has been publicized. To the best of our knowledge, Heartbleed is the first computer systems bug to have both its own website and its own logo, the cute bleeding heart. As such, Heartbleed sets a precedent that will have both positive and negative ramifications for future vulnerabilities and malware.

Heartbleed2The Heartbleed website and logo were developed by the Finnish company Codenomicon, which makes fuzz testing software and provides security test services. Although the bug, officially dubbed CVE-2014-0160, was independently discovered by Neel Mehta of Google and several engineers at Codenomicon, the latter company is the one that turned it into a household word. Even among the vast majority of the population who have no idea what OpenSSL is, people everywhere quickly found out that a major bug could compromise their Internet security. For that, Codenomicon deserves thanks.

In addition, the Internet industry commendably jumped into action, with some websites being patched even before the disclosure became public and many other sites within a few days. (Patches to potentially affected embedded devices may take years, but that’s another story, and the process by which certain firms got early notification of Heartbleed is yet another...)

Despite the cooperation of Internet powers in addressing Heartbleed, VDC sees several disconcerting implications in the way the bug CVE-2014-0160 became Heartbleed the logo.

First, Codenomicon undoubtedly got a huge boost in its profile by virtue of its role in publicizing Heartbleed. Therefore, we anticipate that other security firms will seek similar attention when they discover significant vulnerabilities. We wouldn’t be surprised if discoverers prepare websites and logos before they even disclose the bugs, then flip the switch to launch their sites instantly upon disclosure. That may again produce rapid, coordinated reaction to fix the problem, but it raises questions about possibly overstating the risks associated with lesser vulnerabilities in the name of garnering publicity.

The Heartbleed bug was a biggie, deserving of widespread attention, whereas most bugs are rather mundane. Flaunting them won’t quite constitute crying wolf in the absence of threat, but it may be the equivalent of crying wolf when there’s just a loose dog poking around among the sheep.

Second, prankster-level hackers could conceivably set up fake vulnerabilities web pages, causing temporary wastes of much effort and energy before being debunked. That’s the equivalent of yelling  “Fire!” in a crowded theater.

Third, and most egregious, would be malicious hackers who publicly announce a vulnerability (either real or fake) for the purpose of exploiting a different vulnerability while everyone is distracted with the first one. That’s yelling “Fire!” (or actually setting a fire) in the theater so they can rob a bank across town while the police and firemen are occupied. Password phishing email campaigns can already come in swift response to disclosure of real vulnerabilities. Now, we anticipate hackers coordinating both the disclosure and the phishing campaigns.

Sad to say, despite all the benefits of renewed examination of security protocols that will come out of the Heartbleed bug, there remain many who will seek to maximize their own gains by learning from the reactions of others.

12/10/2013

The AllJoyn Protocol: Does Its Openness Compromise Security?

On December 10, the Linux Foundation announced the formation of the AllSeen Alliance, an industry consortium that seeks to expand the Internet of Things in home and industry. Premier members include: Haier, LG Electronics, Panasonic, Qualcomm, Sharp, Silicon Image and TP-LINK, with more than a dozen additional community member companies.

The members plan to adopt an open-source peer-to-peer communications framework called AllJoyn, originally developed by Qualcomm Innovation Center and launched back in 2011. Qualcomm has now contributed AllJoyn to the Alliance. AllJoyn is hardware agnostic and can run on multiple popular OSs including Linux, Android, iOS, and various Windows desktop and embedded versions (despite the Alliance being announced by the Linux Foundation). You can find technical details of AllJoyn at www.alljoyn.org, so we won’t describe the protocol at length here.

AllJoyn enables devices to interact at the app-to-app level. The protocol handles much of the communication over ad hoc proximity networks, such as Bluetooth and Wi-Fi, with the ability to mix and match devices with different communications protocols, so that apps don’t have to deal with the lower level functions. Qualcomm’s early emphasis was to enable multi-player gaming across a variety of unlike devices, but the AllSeen Alliance seeks to foster adoption across a much broader range of devices in “the Internet of Everything.”

AllJoyn facilitates authentication and encrypted data transactions between devices. But how will AllJoyn prevent unintended devices from joining a group of devices given that the protocol was designed to make device discovery and connectivity as easy as possible?

In the case of Wi-Fi, assuming that the network is set up with proper Wi-Fi Protected Access (WPA), AllJoyn doesn’t make it any easier to gain access to the network without the security key, particularly if the network is set up to allow only whitelisted devices. For Bluetooth, a hacker within range (about 10 meters) conceivably could spoof the identity of a known device, to trick a user into accepting it into the network. In conventional Bluetooth communications, once devices are paired and connected, they could have free reign over numerous applications on each other. With AllJoyn, the protocol can be used to limit which apps can talk to each other on which device. In that sense, AllJoyn should actually increase the security of Bluetooth devices. When combined with encrypted communications, no security holes are obvious (although it’s best to assume that hackers will discover some).

In addition, AllJoyn devices are able to communicate with each other in the absence of any Internet connection, which in certain scenarios will eliminate entire realms of security risk.

VDC expects that the AllSeen Alliance will succeed in gaining acceptance of AllJoyn for consumer electronics and home control applications. But the very names AllSeen and AllJoyn imply a degree of openness that won’t inspire confidence among industrial and critical infrastructure users. The convenience advantages of AllJoyn probably won’t outweigh security concerns for those users.