HomeKit market held back by Apple's high encryption demands - report
The slow trickle of HomeKit-compatible accessories is reportedly linked to a high level of encryption mandated by Apple, said to be generating unusuable levels of lag in prototype Bluetooth products.
HomeKit encryption standards require that accessories use 3,072-bit keys, and Curve25519, an elliptic curve for signatures and key exchange, according to Forbes. While this is manageable for devices communicating via Wi-Fi, ones using Bluetooth Low Energy (LE) are said to be running into processing barriers.
A spokesman for Elgato commented that one Bluetooth-based sensor it had in development was initially taking up to 40 seconds to determine if a door was open or closed. An anonymous source at another company meanwhile claimed that lag reached up to 7 minutes on a device.
The second person remarked that various makers of Bluetooth LE chips -- like Marvell and Broadcom -- are working to improve their designs to handle Apple's encryption demands. Apple itself is allegedly aware of the lag problem.
In the meantime, Elgato is coping via optimized firmware and extra onboard memory, and planning to sell its workarounds to other accessory makers. To date, the company is the only HomeKit accessory maker with Bluetooth products.
Other obstacles are allegedly hampering HomeKit development as well. Forbes' sources said that HomeKit code wasn't at a level for MFi (Made for iPhone/iPod/iPad) certification until two months ago, and Apple insists that every change to a product be resubmitted. The latter issue is relatively normal for the MFi program.
Apple's encryption demands are presumably a way of deflecting any worries about using HomeKit products. Whereas someone hacking into an iCloud account might gain access to photos, contacts, and important documents, hacking into a HomeKit network could open up real-world access to someone's home or cause havoc with lighting and appliances.
HomeKit encryption standards require that accessories use 3,072-bit keys, and Curve25519, an elliptic curve for signatures and key exchange, according to Forbes. While this is manageable for devices communicating via Wi-Fi, ones using Bluetooth Low Energy (LE) are said to be running into processing barriers.
A spokesman for Elgato commented that one Bluetooth-based sensor it had in development was initially taking up to 40 seconds to determine if a door was open or closed. An anonymous source at another company meanwhile claimed that lag reached up to 7 minutes on a device.
The second person remarked that various makers of Bluetooth LE chips -- like Marvell and Broadcom -- are working to improve their designs to handle Apple's encryption demands. Apple itself is allegedly aware of the lag problem.
In the meantime, Elgato is coping via optimized firmware and extra onboard memory, and planning to sell its workarounds to other accessory makers. To date, the company is the only HomeKit accessory maker with Bluetooth products.
Other obstacles are allegedly hampering HomeKit development as well. Forbes' sources said that HomeKit code wasn't at a level for MFi (Made for iPhone/iPod/iPad) certification until two months ago, and Apple insists that every change to a product be resubmitted. The latter issue is relatively normal for the MFi program.
Apple's encryption demands are presumably a way of deflecting any worries about using HomeKit products. Whereas someone hacking into an iCloud account might gain access to photos, contacts, and important documents, hacking into a HomeKit network could open up real-world access to someone's home or cause havoc with lighting and appliances.
Comments
Which, currently, NO security encryption is NOT good enough.. even though the smart home OEM's seem to think it is..
If I am going to load up my house with this stuff it will be nice to know that they have taken all precautions to ensure my security web cam isn't being broadcast to the world or that some idiot doesn't program my AC or Heating to MAX while I am out or worse yet, allow burglars to disable the system and open the doors. RIGHT ???
As a developer, I can understand the hassles of what high-encryption can bring in terms of performance. That being said, it's about damn time ANY company demands it. How many countless stories have we read over the years with hackers cracking into home equipment and stalking the people? The industry had all these years to do it, and always decided to ship their products with half-a$$ securities, no passwords, or whatever. Shame on them, good on Apple.
As usual, Apple has to be the one to pave the way (or give a swift kick to their backside) to take product-security seriously.
Remember those scary incidents with wireless baby monitors being hacked and some nut job talking (cussing) to an infant or parent? If this were an Apple product, I'd bet money the haters and trolls would be asking for Apple's head, but since there were mainly some cheap-asian junk.. no one cares.
Kudos for Apple. Watch the Samsung-lovers claim that it was the industry evolving, and not because of Apple's demands.
Thanks Apple for the requirements. I don't want to go home with my smart-lock door wide open because of hackers.
As a developer, I can understand the hassles of what high-encryption can bring in terms of performance. That being said, it's about damn time ANY company demands it.
I don't think the manufactures mind programming the encryption, and it works acceptably over WiFi. It is using a high bit level on BT LE that is creating the unacceptable overhead. Most SSL servers on the Internet today are still using 2048 so 3072 is a bit higher than the norm.
It is a hardware issue not a software issue.
Sounds like a pretty good advertisement tagline.
"so secure, not just anyone can get in".
These manufacturers are used to standards created by committee and arbitration rather than fiat. You know, the kind of standards that result in lowered specs to make it easy for substandard implementations to meet them.
I really don't think this is the case here. The chips have to be certified by Apple from the likes of Marvel and Broadcom. The encryption is standards based TLS. The BT LE chips are just not up to the task of 3072 bits. The fact that Elgato, which is a really high quality manufacturer is identifying and also helping to create a workaround indicates that it is not an issue of substandard implementations.
Most of the overhead in creating an SSL connection is in the handshake which is where all the encryption algorithms are done. If you use SSL sessions, which is what it looks like Elgato is doing by copying the session to memory, after that, subsequent connections are faster. A connection such as mentioned in the article about taking 40 seconds to find out if a door is open is probably the first handshake session. After that it may be a bit faster, but in a home security situation 40 seconds is too long.
This is what happens when you don't use strong enough security: you get people breaking in using brute force attacks:
http://www.cnet.com/news/gone-in-60-seconds-the-high-tech-version/
I'm all psyched to try this. It connects to the house WiFi system and also can interface tiny remote sensors over WiFi to monitor activity and temperature in remote rooms.
Since it uses WiFi for everything, I expect it to be robust enough to provide instantaneous response.
FWIW, 2 of the tiny remote sensors retail for $79 (including stand, casing, battery, packaging, etc.) -- So how costly can the WiFi chips be?
I don't think the manufactures mind programming the encryption, and it works acceptably over WiFi. It is using a high bit level on BT LE that is creating the unacceptable overhead. Most SSL servers on the Internet today are still using 2048 so 3072 is a bit higher than the norm.
It is a hardware issue not a software issue.
I agree with you. I think the lack of any serious security solutions meant that they could skimp on the hardware side as well. Now, the industry will have to take hardware-level encryption performance seriously for their HomeKit products. This can only benefit the industry as a whole. It just took Apple to tell everyone to get its act together.
Now, the industry will have to take hardware-level encryption performance seriously for their HomeKit products.
Makes you wonder what the BT LE bandwidth capability is on iOS devices themselves.
I don't think the manufactures mind programming the encryption, and it works acceptably over WiFi. It is using a high bit level on BT LE that is creating the unacceptable overhead. Most SSL servers on the Internet today are still using 2048 so 3072 is a bit higher than the norm.
It is a hardware issue not a software issue.
Really, unnacceptable overhead? What the hell traffic are they putting through those networks? Home kit data requirements isn't exactly massive is it? The latest blue tooth can handle 100 times that.
What they object too is the fact they were using cheap ass old chips and they have to pay a bit more for better performing one (even dedicating some to encryption). That's were the rub is. Considering how little the actual hardware is actually part of the final pricing of those devices, the objection is a bit crazy. Pass on the extra $1 to the end user of your $100+ device and call it a day.
Maybe they bought the old chips in bulk and don't want to be stuck with them :-).
If the SSL handshake is overly complex for BLE I would think a WiFi bridge might offer an acceptable solution for many non-security devices -- like the Phillips Hue. You would interface the Bridge with WiFi from an iDevice -- and the bridge would monitor/control the individual accessories (lights) via BLE.
Though, any devices requiring security should be WiFi.
If the SSL handshake is overly complex for BLE I would think a WiFi bridge might offer an acceptable solution for many non-security devices -- like the Phillips Hue. You would interface the Bridge with WiFi from an iDevice -- and the bridge would monitor/control the individual accessories (lights) via BLE.
Though, any devices requiring security should be WiFi.
Apple requires that the device itself deploy 3072 bits and elliptic curve in order to be certified, so even if you did use a Wifi bridge, the bridge would need to still send encrypted keys to the BT device. 3072 is a lot of data. For example, currently, 2048 is considered secure for about 4 years from continuous brute force by a super computer. With current BT LE chips, 3072 might be secure for a century considering that each iteration of the brute force attack takes 40 seconds to execute. /s
One thing's for sure, I wouldn't want to have someone break into my house with no signs of entry (therefore, no evidence to present to police) and steal all my stuff.
Though, any devices requiring security should be WiFi.
At this point it looks like any HK device should be Wifi. The thing about a sensor to detect a door being open, a homeowner might not want to spend thousands of dollars rewiring every window and door in their home with AC or LV power. Wifi probably uses a lot of battery where as BT LE does not, plus the homeowner could DIY the project. Let us know how your new wifi sensors work out for your new HVAC.
Translation of gobblespeak :
- Manufacturers who are too cheap to put a CPU able to handle the encryption want Apple to lower the security of the system.
Translation of gobblespeak :
- Manufacturers who are too cheap to put a CPU able to handle the encryption want Apple to lower the security of the system.
Wrong. The devices handle the encryption just fine over WiFi. Manufacturers want BT LE chips that can handle the amount of bandwidth required for 3072 bit encryption. The chips certified by Apple from Marvell and Broadcom cannot handle that much data, at least not quickly enough.
I swear does no one read the article?