Apple HomeKit Requires ID Chip

SAN JOSE, Calif. – Apple Inc. requires anyone making a device compatible with its HomeKit environment to buy and use a special identity chip. The revelation was one of many from a session on platforms for the Internet of Things at last week’s ESC SV event here.

“I know a lot of people who have been surprised by this requirement and had to re-spin boards for the chip,” said Michael Anderson, chief scientist of PTR Group in his talk. “A lot of manufacturers are up in arms [about the] Apple silicon [that makes their] device more expensive,” he said.

“There’s no clear story what the chip does but I expect it is involved with access to the cloud and may have triggers for geo location,” Anderson said. Overall, “there’s not a lot known about HomeKit since it was first launched in iOS 8 because Apple’s got it under wraps,” he added.

Apple did not answer three requests for information from EE Times about the chip’s function and cost. HomeKit is just one of as many as seven consumer IoT platforms, Anderson discussed.

“There’s no shortage of IoT platform offerings, there are dozens of them -- most of them run Internet Protocol, often support 802.15.4 and have similar messaging systems such as MQTT or RESTful APIs, and open source is the focus for many of them,” he said.

Anderson cautioned engineers to be wary given shades of grey in what open means for some platforms. For instance, he noted the Intel-led Open Interconnect Consortium (OIC) requires diamond sponsors to pay $350,000 per year while gold members must pay at least $1,000 per year just to get specifications.

“There’s a price to buy in and get access to information even though it’s sponsored by the Linux Foundation -- the whole buy-in thing is a bit iffy if you ask me,” he said.

For its part, the Thread Group, led by Google’s Nest division, uses the 802.15.4 standard for its transport layer, but higher layers are “less open, so they may need industry pressure to open up,” he said. It also charges $2,500 per year to obtain specs, he said.

“It’s like open source, sort of, and we’ll see more of this over time…closed source implementations will dominate for the time being,” he said.

That said, most of the competing consumer IoT software platforms embrace multiple operating systems and protocols.

For instance, Intel’s IoTivity implementation of the OIC specs supports CoAP, MQTT and RESTful apis as well as Linux, Tizen and Arduino. AllSeen, also hosted by the Linux Foundation, supports multiple operating systems and APIs and D-Bus for message discovery.

Companies are hedging their bets, backing multiple options. “AllSeen is what Microsoft backs in Windows, Qualcomm [which created the technology behind AllSeen] just joined Thread” as did the Zigbee Alliance, he noted.

The industrial IoT holds even broader opportunities than the consumer sector. That fact is drawing “the attention of major players [given big buildings such as] the Frankfurt air terminal has 80,000 sensors…this is big business,” he said.

ThingWorx is “one of big platforms in this area covering everything from gateways to the cloud.” Its requirement for 32 Mbytes memory for clients means it will not see significant use in end nodes, he said. In addition it lacks “a good clear story on end-to-end security, but it supports all the major APIs and has a wide ecosystem from semiconductors to systems and software,” Anderson said.

Similarly, Xively provides a framework covering gateways and cloud services, as does Etherios, a subsidiary of Digi focused on fleet management, medical devcies and manufacturing. Among up-and-coming alternatives, ThingSquare launched on Kickstarter, but “they are still trying to figure out what they want to be when they grow up,” he said.

Other options include the Kaa Project, ThingSpeak and at least three frameworks under the Eclipse Foundation including Koneki and Mihini, he said.

The Apple-approved coprocessors and firmware provide secure communications between apps running on iOS devices and the manufacturers' smarthome gizmos.

There is more information in the net if you look around. And, as you correctly mention, the platform solutions from vendors like Broadcom, Marvell, Mxchip and integrators like Lifx, you can read in their documentation or see in their reference design schematics that they indicate the need of the Apple authentication chip for HomeKit support. Their evaluation boards either connect to a breakout board with the device (eg Marvell) or provide a footprint for the chip (eg Broadcom WICED) so end customers can directly solder development or serialized end-product chips to them.

The only (mostly) open-source solution with HomeKit support that I am aware of is the MICO platform from Mxchip. The communication with the coprocessor is obviously provided in binary form since that information is covered by the Apple MFi NDAs.

BTW, kudos for the implementation of HomeKit in the nRF51. We tried hard and we could never get the 3072-bit calculations down to the timings required by specs. We tested your solution and it performed flawlessly.

I reread the The Register article a couple of times, and actually it doesn't really talk about the authentication chip (which is what Rick Merritt referred to in his article, the "Apple silicon").

The Register refers to certified HomeKit hardware/software solutions by chip vendors, typically a hardware development kit plus a HomeKit SDK. There are such Apple-approved offerings from Broadcom, Marvell, and as I mentioned earlier from Nordic Semiconductor.

Based on these development tools, companies can then develop their accessories, designing in one of these communication chips and the HomeKit Accessory Protocol implementation that comes with its HomeKit SDK.

The article is wrong though in some aspects. For example, such a HomeKit SDK contains no Apple firmware. HAP is implemented either by the chip vendors themselves, or our OberonHAP implementation is licensed by the chip vendors.

Yes indeed. It should be well known that Apple has the MFi program for companies designing accessories for Apple devices. If a company registers for it, which is free, it can get access to the HomeKit specifications. If they do that and read them, they will not be surprised about the requirement for using the venerable Apple authentication chip as described in the Register article.

"May have triggers for geo location"? Nonsense...

To expel another common myth: the authentication chip does not process the computationally expensive parts of the HomeKit Accessory Protocol (HAP), like ChaCha20 and Curve25519. These must be executed by the microcontroller of the accessory. Unfortunately, good microcontroller implementations have only started to arrive on the market. The first generation implementations seem to be abysmally slow and memory hogs, if various recent reports on the Web can be believed. In particular, Bluetooth Low Energy accessories may have been delayed because of this, due to their typically slower microcontrollers.

However, this is not an inherent problem with HAP: our second-generation OberonHAP implementation made HAP feasible even on a 16 MHz Cortex-M0 with 32 KB of RAM, like a Nordic Semiconductor nRF51 chip (Nordic's HomeKit SDK is based on OberonHAP). And we will soon have completed an even more optimized third-generation implementation (http://oberonhap.com).

Here two official Apple sources that shed a bit more light on what they do in HomeKit:

"There's no clear story what the chip does but I expect it is involved with access to the cloud and may have triggers for geo location."

Pfff.... Really? A simple web search would have hinted that it is the same "iPod" authentication co-processor vendors need to put in their devices to certify that a device is Apple-compatible. This is well known. For example, The Register posted about it a couple of weeks ago... http://www.theregister.co.uk/2015/07/13/security_apple_homekit_delays.

I don't see how this could be much different from needing any other specialized hardware to talk to other home automation systems. In particular if they have an 802.15.4 radio that requires a bridge or a dongle when using a smart phone or a personal computer.