HomeKit market held back by Apple's high encryption demands - report

Posted:
in iPhone edited July 2015
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.
«13

Comments

  • Reply 1 of 46
    adrayvenadrayven Posts: 460member
    Good, I'd rather it be secure.. We've had far to many on the mindset of 'good enough' mentality.

    Which, currently, NO security encryption is NOT good enough.. even though the smart home OEM's seem to think it is..
  • Reply 2 of 46
    jungmarkjungmark Posts: 6,690member
    Market isn't held back by Apple's encryption requirements. It's held back by vendors not able to produce software/hardware to align with Apple's encryption requirements.
  • Reply 3 of 46
    I'm kinda hoping that this isn't a critique of their security requirements.

    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 ???
  • Reply 4 of 46
    sflocalsflocal Posts: 4,618member

    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.

  • Reply 5 of 46
    fallenjtfallenjt Posts: 3,976member

    Thanks Apple for the requirements. I don't want to go home with my smart-lock door wide open because of hackers.

  • Reply 6 of 46
    mstonemstone Posts: 11,510member
    Quote:

    Originally Posted by sflocal View Post

     

    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.

  • Reply 7 of 46
    airnerdairnerd Posts: 664member

    Sounds like a pretty good advertisement tagline.  

     



    "so secure, not just anyone can get in". 

  • Reply 8 of 46
    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 remember when "HD" was dumbed down by bandwidth starved satellite providers who wanted HD to mean 720p (or 1440x1080i) instead of 1920x1080p, which was later named "Full HD". Consumers got fleeced.
  • Reply 9 of 46
    mstonemstone Posts: 11,510member
    Quote:
    Originally Posted by Suddenly Newton View Post



    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.

  • Reply 10 of 46
    airnerd wrote: »
    Sounds like a pretty good advertisement tagline.  



    "so secure, not just anyone can get in". 

    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/
  • Reply 11 of 46
    dick applebaumdick applebaum Posts: 12,507member
    The AC guy is here (working on a condensation leak in the heat exchanger). When he finishes he will replace the thermostat with the Ecobee3 HomeKit enabled Thermostat.

    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?
  • Reply 12 of 46
    sflocalsflocal Posts: 4,618member
    Quote:

    Originally Posted by mstone View Post

     

    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.

  • Reply 13 of 46
    mstonemstone Posts: 11,510member
    Quote:

    Originally Posted by sflocal View Post

     



    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.

  • Reply 14 of 46
    foggyhillfoggyhill Posts: 4,767member
    Quote:
    Originally Posted by mstone View Post

     

    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 :-).

  • Reply 15 of 46
    dick applebaumdick applebaum Posts: 12,507member
    mstone wrote: »
    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.


    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.
  • Reply 16 of 46
    mstonemstone Posts: 11,510member
    Quote:
    Originally Posted by Dick Applebaum View Post





    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

  • Reply 17 of 46
    I'm not an expert on any of this stuff (as most people aren't), but it seems to me that if Apple has placed high demands on encryption of partner products, they have a damn good reason for it and the partners had better step up their engineering.

    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.
  • Reply 18 of 46
    mstonemstone Posts: 11,510member
    Quote:
    Originally Posted by Dick Applebaum View Post



    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.

  • Reply 19 of 46
    lukefrenchlukefrench Posts: 102member

    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.

  • Reply 20 of 46
    mstonemstone Posts: 11,510member
    Quote:
    Originally Posted by lukefrench View Post

     

    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?

Sign In or Register to comment.