Travis Goodspeed just published his BlackHat 2009 paper on key extraction from Zigbee SoCs on his blog. It's scary that most of the new meters going into the smart grid are based on the chips which have the vulnerability he mentions in the paper. I don't think it's a coincidence and the implications are very severe. I've included the paper below and you can download it from his website. If you're in the 802.15.4 or Zigbee industry, you should definitely check this out...

Updated 2009-08-07: Travis also mentions he'll be announcing fixes for the security vulnerabilities in future blog posts as well.

One of the questions I get most often is about how the Zigbee Cluster Library works. If you just read the spec, then it’s not immediately obvious because many things are implied. Also, you often have to read the Zigbee spec in conjunction with the Zigbee Cluster Library spec in order to understand how things work because specific parts of the functionality are written in each. However the big thing that people have problems with is implementation. The Zigbee Cluster Library is written in the concept of object oriented programming where everything is abstracted. However actual implementations will usually be written in C which does not have these facilities. Thus there’s a significant architectural challenge to map the abstraction of the Zigbee Cluster Library into a language like C. Since I’m updating my documentation about the ZCL to reflect some recent changes I’ve made to it, I thought that some of the material might be useful in a ZCL tutorial. I’m skipping a couple of layers with this tutorial, but I figure there’s no rule that I need to go in order. Hence, with no further ado…

The Zigbee Cluster Library defines a generic interface to the Zigbee stack and consists of attributes and commands. The attributes contain data about that interface, and the commands initiate actions for it. An example is the ZCL’s level control cluster. The “current level” attribute contains the data value that represents the current level of something, ie: a dimmable light. The “move to level” command initiates an action, where the current level will transition to a new level specified in the command’s arguments. That example pretty much summarizes the functionality of the Zigbee Cluster Library.

The difficulty with the ZCL, and the part that I get a lot of questions about, is that it is a completely generic interface. All clusters have the same interface, in that they can contain both attributes and commands. The attributes are also generic, meaning that an attribute can contain any type of data. One attribute could be a character string and another attribute can be an unsigned integer. In object oriented terms, an attribute exhibits polymorphism where an unsigned char attribute can be used like a string attribute. In C, this is not so easy to accomplish.

Before we get into the details of the FreakZ implementation, it might be good to get an idea visually of what the ZCL is. Here’s a diagram that illustrates how a device profile is put together using clusters from the ZCL.

ZCL Overview

From the diagram you can see all the basic building blocks. The most basic block is the attribute. Multiple attributes are aggregated into an attribute list. Clusters consist of attribute lists and command parsers. Groups of clusters are aggregated into a cluster list. And finally, the cluster list is tied together by the simple descriptor and the frame handler to create a device. Each device is located on a separate endpoint.

When I first started this blog, I talked about Zigbee on Google Trends . This was in March, 2008. I recently checked again and there's a noticeable difference in news reference volume which means that Zigbee is getting much more press coverage than back when I originally made the post. Here's the picture from March 2008 and the most recent one.

 March 16th, 2008

 

 

June 16th, 2009

 

I’m not sure if a lot of you are familiar with this, but there is currently an effort to develop a Zigbee stack native to Linux . The effort is spearheaded by people from the Siemens Embedded Systems – Open Platform group and they have already released some 802.15.4 code for the project . However, a recent issue came up on the Linux Kernel Mailing List (LKML) regarding Zigbee and it’s compatibility with the GPL that may possibly de-rail this effort. The issue is important because any efforts for a protocol stack, or any software for that matter, to get integrated into the Linux kernel will be useless if it can’t comply with the terms of the GPL. The issue in question is in regards to the first paragraph of the “Notice of Use and Disclosure” statement in the public Zigbee specification:

The ZigBee Specification is available to individuals, companies and institutions free of charge for all non-commercial purposes (including university research, technical evaluation, and development of non-commercial software, tools, or documentation). No part of this specification may be used in development of a product for sale without becoming a member of ZigBee Alliance.
Although there’s no problem for GPL compliance for non-commercial projects, a commercial project will not be able to use the Zigbee specification, and thus no Zigbee software, unless the individual or group becomes a member of the Zigbee Alliance. Here’s where the issue occurs. The Zigbee Alliance membership fee for the lowest tier, Adopter (of which I am), is $3500. Hence, the above statement becomes analogous to an IP licensing agreement for a minimum sum of $3500 for any commercial project. This would be in violation of term 2-c of the GPL:

2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

    * a) The modified work must itself be a software library.
    * b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
    * c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
    * d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.

Although the open source community is traditionally indifferent to anything that is ‘commercial’, the GPL does not make any distinction between commercial and non-commercial. Its requirement is basically that the source code must remain open and free of licensing fees. In this case, the licensing fee isn’t imposed by the author but by the owner of the specification’s IP. Hence the quandary that the LKML post opens up.

When I first heard about the issue, it was from an email by the original poster, Jon Smirl, who incidentally has his own blog over at http://www.digispeaker.com. I have to admit, I was skeptical since I figured that Bluetooth was integrated into Linux and the spec has the same requirements, where you have to be a member to use it. However after a bit more investigation, it turned out that the Bluetooth Adopter membership was free which would remove the GPL violation.

With Zigbee’s recent announcement of its bid for IEC standard approval on its Smart Energy Profile, the announcement of the move towards IPv6, and the US Department of Energy’s requirement for open standards for the smart grid, I’m wondering if the membership restriction for Zigbee’s IP usage is even relevant anymore. A viable alternative would be to require membership for usage of the Zigbee logo/trademark, and for certification testing and recognition. This would be the same model that the USB-IF is using, where the spec is free to use, but the logo and certification requires a USB-IF membership. Anyways, most companies join for early access to the specs and lurking the internal mailing lists for any juicy gossip so I doubt membership would suffer.

I’ve already brought this issue up on the Zigbee Alliance internal mailing list and am very interested in the outcome. The FreakZ project is also covered by the GPL so this would affect my software as well. If the outcome is unfavorable, ie: the GPL can’t be used, then the FreakZ project will still continue, however I’ll have to put a lot of thought into which license to use. Apparently, everyone wants me to go BSD…already heard it about a thousand times...

I’m really hoping that Zigbee will stay true to their word of moving the spec to become more of an open standard. Linux kernel adoption would be a huge statement that it is, in fact, open which would earn brownie points in the eyes of the US Department of Energy as well as European and Asian energy agencies and energy utilities. Also, if the protocol stack does get adopted into the Linux kernel, it may provide the key to markets such as handsets (Android), set-top boxes (TiVo), and networking gear (uhhh…like all routers). These are markets that other protocols are drooling over.
 
Well, I’ll be the first to admit that I’m not an expert in IP law. If anyone has anything to say, either for or against, please feel free to comment. Let’s not turn this into a holy war, though.

 

Welcome back to my ongoing series of Zigbee tutorials on the soon-to-be obsolete Zigbee Networking layer. Now that we’ve finished covering the data path, it’s time to look at the network management services. It’s quite a wide topic so I’ll start with the main management services and then cover some of the more esoteric ones later. Before we begin, I think it might be good to give a quick peek ahead on how a user application would interface to the networking layer to manage the network. With a top-down view, things might make more sense than just listening to me talk about some abstract next higher layers that all the data magically goes to or comes from.

Brief Overview

Whereas the Zigbee networking data path logically follows the protocol stack layer hierarchy, the network management deviates somewhat from it. Since this may be a bit confusing, let me try to explain it briefly.

The application layer consists of three parts: the Application Sublayer (APS), the Application Framework (AF), and the endpoints. The Application Sublayer interfaces the Zigbee application layer to the Zigbee networking layer and it provides a common set of data transport services to all the endpoints. There are also a couple of other services that the APS provides and we’ll get into that when we discuss the app layer in more detail.

The Application Framework is just a glorified multiplexer and container for all of the endpoints. All of the endpoints register themselves with the AF, and when a data frame comes into the application layer, the AF will check its destination endpoint and forward it there.

The endpoints are what most people associate with Zigbee. Each endpoint houses what’s called an application object which is basically a device profile with whatever extra functionality you decide to add. When the device is started, all the endpoints will register themselves with the application framework and provide descriptions of their device profile and their capabilities. Endpoint 0 is a special endpoint and always contains the Zigbee Device Object (ZDO). This object implements the Zigbee Device Profile which has multiple functions, one of them being the network manager.

The user application can manage the network by making requests and handling callbacks to this object, which is why it’s important to know about it. In general, the Zigbee endpoints are going to be the main interface between the user application and the stack.

When I mentioned that the network management deviates slightly from the stack’s layer hierarchy, what I meant was the ZDO’s network manager object bypasses the APS and interfaces directly to the networking layer. Thus, you get a bizarre looking layer stackup like this where you can see the ZDO wraps around the APS and the NWK layers.

Zigbee Architecture

(Graphic gratuitously copied from from Zigbee Open House - Seoul, 2006 - Phil Jamieson)

You can also forget about all of those SAPs (service access points) between the layers, since they’re mostly there for formality. In a real implementation, you would just call the functions directly or via function pointers.

With that out of the way, we can take a look at a few of the main network management functions.