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'd guess cost is only part of the equation. From what I recall, a WiFi chip uses a lot more power than a low-power Bluetooth chip (200-300 mA peak vs 15), so I'm guessing they are trying to use BT so they can increase battery life.
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'd guess cost is only part of the equation. From what I recall, a WiFi chip uses a lot more power than a low-power Bluetooth chip (200-300 mA peak vs 15), so I'm guessing they are trying to use BT so they can increase battery life.
The WiFi Motion and Temperature Sensor uses a 3V Lithium battery -- likely last a year???
So, basically these companies are moaning because they can't get away with using old chip designs because Apple are pushing them to be better. Boo hoo!
As an app developer, I can tell you that Apple has broken the Bluetooth standard (that they helped define) by hiding the unique IDs it is based upon from developers. This is being done by Apple's SDK not the device itself. For WiFi the situation is vastly worse. There is not and never has been a WiFi SDK for iOS making life very difficult for both developers and users alike. It is far easier to setup a Nest smoke detector on an Android device than an iOS device. In most other ways iOS is a better user experience but something is stopping Apple from providing a SDK to this supposedly public and free networking standard.
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
3072 bits is only 384 bytes, not much data. BT LE can handle Mbps speeds, think BT streaming to a cars audio system. The problem is in the amount of work that the encryption/decryption hardware has to perform to obtain a result that is then transmitted via BT in whatever device is used, powered by coin batteries.
I am actually surprised the Apple hardware guys haven't developed a high security SoC just for IofT interfaces.
Ideally encryption is used to protect unspecified data from unknown 3rd parties. However, I'm thinking that a door lock is not sending this, more likely locked or unlocked, basically a known plaintext, which then may make most of encryption susceptible to quicker attacks at obtaining the master key.
Does anyone know if these devices when used with HomeKit, generate their own unique keys or hashes that are associated with commands, that are then encrypted for transmission?
3072 bits is only 384 bytes, not much data. BT LE can handle Mbps speeds, think BT streaming to a cars audio system. The problem is in the amount of work that the encryption/decryption hardware has to perform to obtain a result that is then transmitted via BT in whatever device is used, powered by coin batteries.
I am actually surprised the Apple hardware guys haven't developed a high security SoC just for IofT interfaces.
BT LE does NOT handle Mbps speeds. BT 2.0+EDR does and so does BT 3.0+EDR. LE in BT LE stands for Low Energy, and the primary goal is to have a very low energy consumption, and NOT high speeds. BT LE is designed for very infrequent and small amounts of data, like reading a heart rate monitor. It typically transfers only a few bits or bytes in total, and not kilobytes.
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.
It's been held back by "just good enough is profitable"
The problem isn't Apple here, the problem is that the hardware vendors are choosing to use cheap unreliable parts in the first place.
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.
I'm willing to bet damn near nobody in this forum actually works as trade electrician.
1) Low Voltage != Low Amperage. A typical HVAC or Lighting system has Low Voltage control panels connected to a High Voltage central relay. Some Furnaces that are gas powered, have the controls actually powered by a Pyroelectric generator.
2) You don't want AC power running everywhere, but you don't want a single DC power rail being generated at a central point due to energy losses.
So if you were building a house, from scratch, you would actually want to put all the Low Voltage wiring in parallel to the A/C wiring, but in separately insulated conduits so that any damage to the A/C wiring in the future doesn't short circuit and destroy every LV connected device in a blink of an eye. But you're still forced to rip up your walls to add things. So you won't EVER be doing this in a Condo or Apartment.
Conventional doors (eg the ones that swing open) and Windows (that swing open) have no means of putting power "in the door" without resorting to batteries. If you run power through the hinges, that turns the door into a potential death trap or fire hazard. The correct way to go about this is to actually reverse the position of the door knob and the door latch. Yes... put the door knob and deadbolt into a much thicker frame, and have nothing on the physical door. For Windows, it would require thicker window frames, but the same idea, and I've seen it before on some skylights. You just have an electro-mechanical "scissor lift" that is locked by mechanical resistance when there is no power.
But Bluetooth LE flips the situation around, and instead of running LV wiring everywhere that you can't fix withour ripping up your walls, you can now piece-meal put controls where you need them. So this stuff is primarily targeted at city-dwellers who do not have the option to demolish parts of their units because it would infringe on their neighbors or damage the building environment envelope.
3072 bits is only 384 bytes, not much data. BT LE can handle Mbps speeds, think BT streaming to a cars audio system. The problem is in the amount of work that the encryption/decryption hardware has to perform to obtain a result that is then transmitted via BT in whatever device is used, powered by coin batteries.
I am actually surprised the Apple hardware guys haven't developed a high security SoC just for IofT interfaces.
The 3072 bits is not the overall issue. RSA encryption is not a direct conversion from bits to bytes. 3072 is a huge amount of data. Plus it needs to be decrypted on the other end, all very processor intensive not to mention the curves. It is the algorithms of the handshake that causes the lag. I'm getting very tired of responding to people who have no understanding of the actual issues at hand.
Your comment made it sound like the BTLE communication bandwidth is to small and is the problem, which is not the problem. I agree that it has to do with the processing.
BT LE does NOT handle Mbps speeds. BT 2.0+EDR does and so does BT 3.0+EDR. LE in BT LE stands for Low Energy, and the primary goal is to have a very low energy consumption, and NOT high speeds. BT LE is designed for very infrequent and small amounts of data, like reading a heart rate monitor. It typically transfers only a few bits or bytes in total, and not kilobytes.
According to the wiki BTLE which is a part of Bluetooth smart has OTA 1 Mbit/s and application speed of 0.27 Mbit/s.
The 3072 bits is not the overall issue. RSA encryption is not a direct conversion from bits to bytes. 3072 is a huge amount of data. Plus it needs to be decrypted on the other end, all very processor intensive not to mention the curves. It is the algorithms of the handshake that causes the lag. I'm getting very tired of responding to people who have no understanding of the actual issues at hand.
In the first post where you seemed to blame throughput rather than processing (I do admit to not reading the article fully so I am at fault for that part). Lunderman said the same thing. Even there, it is basically the fact most companies that use those chips don'T give a crap about encryption that led to them being underpowered in that capacity (chip makers didn't see the point of upping the capabilities of their hardware to serve a non existent need from IOT equipment makers ), so I'm not letting them off the hook regardless.
People have been discussiong the possibly insecurity of the com channels and the net stack in the IOT for several years (at least 3-4) and companies and chip makers should already have had adequate solutions in place to handle this. I know these things a low power and thus cannot be A9... But, they can do better than what they've done up now. Apple basically forced their lazy hands.
Okay, after reading the Forbes article I'm left wondering who mangled whatever information they have, because to be frank, none of these timings are even in the ballpark of what you can do on an off the shelf Bluetooth LE chip. I've actually run some tests (http://github.com/aanon4/HomeKit) on this stuff using a Nordic Bluetooth chip (ARM Cortex-M0 @ 16MHz) and the timings quoted are ridiculous.
The actual HomeKit protocol can be split into two main pieces - pairing (done once) and general control (done often). The pairing on the Nordic chip will take you 40 seconds to complete. It's not fast, but you do it once. This is where you exchange those 3072 bit keys and yes that does seem excessive - but it's entirely doable (and uses an algorithm called SRP developer at Stanford almost 20 years ago). And, as I say, you only do it once. You certainly don't need to do it every time you open a door. Opening a door - the general control piece - uses the Curve25519 algorithm to do a Diffe-Hellman key exchange to establish a unique, per session, shared key between the phone and the device. The reference implementation in C is slow, but it would still only take 10 seconds to open the door - hardly 7 minutes. If you use an optimized version, you're down in the 1-2 second arena (you can probably do better). Also the keys used here are tiny - around 32 bytes - so you're not exchanging large data packets when you're opening the door.
Finally, let's not forget that the Broadcom chips are much more capable than the older Nordic chip on which these numbers are based.
I don't think the problem will be the BTLE data rate. The problem will be the calculations in the key exchange. SRP (the protocol they are using) has a Diffie Hellman like handshake which means the puny computer in your "smart garage door opener" is expected to raise numbers (in this case the number 5) to 256-bit powers, mod a 3072-bit value. That would make even a fast desktop computer pause for a second or two, and makes these little devices pause for tens of seconds.
Perhaps instead they could do one handshake per day (e.g. in the middle of the night) and exchange enough session keys for the whole next day.
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.
Exactly. Forcing stronger encryption makes companies innovate and create better products that help serve them and the consumer. This tech is still in its infancy for the average consumer. Better to get it right than to lead to a bad customer experience, turning consumers away from trusting and using this tech in the future. Especially where home security (door and window locks, security cams etc.) is concerned.
Let's just leave it wide open, so anyone driving past your house can turn the lights on or off...
Have you seen those SmartLocks in the store for your doors? It allows you to easily switch to a new key. They're everywhere, even in locks that work with a App. The only problem is it's mostly plastic inside and using a simple tool you can buy on the internet, Break right in, in the matter of a few seconds!!!! You can see this done on Youtube. These SmartLocks are the ones that have a tiny hole next to where the key is.
It's true that it can use speeds up to 0.27 Mbps, but that is also an "instant battery drain mode", which is NOT what BLE is intended for.
As I wrote earlier BLE is intended for very small amounts of data, like iBeacon or stuff that you read infrequently like the bathroom scale, or a heart rate monitor. The typical data size is around 10-20 bytes, and it is sent at a low speed to conserve energy.
If you set them up as iBeacons or some other low-energy application, then the battery lasts for a year or more. The only way to program these is by sending over BLE, so all firmware upgrades and applications I write for them are transferred via BLE. You can only do a few of these program/firmware transfers, before the battery i drained. I can easily drain the battery in a day or two, when using faster transfers.
I bet you don't want to replace your batteries daily, or even weekly. I think you expect your door locks battery to last for at least a couple of months.
Comments
The latest blue tooth can handle 100 times that.
Maybe they bought the old chips in bulk and don't want to be stuck with them :-).
Read the article. They use Bluetooth Low Energy chips certified by Apple. (It's not Bluetooth. It's Bluetooth LE. Two different things)
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'd guess cost is only part of the equation. From what I recall, a WiFi chip uses a lot more power than a low-power Bluetooth chip (200-300 mA peak vs 15), so I'm guessing they are trying to use BT so they can increase battery life.
Let's just leave it wide open, so anyone driving past your house can turn the lights on or off...
The WiFi Motion and Temperature Sensor uses a 3V Lithium battery -- likely last a year???
Boo hoo!
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
3072 bits is only 384 bytes, not much data. BT LE can handle Mbps speeds, think BT streaming to a cars audio system. The problem is in the amount of work that the encryption/decryption hardware has to perform to obtain a result that is then transmitted via BT in whatever device is used, powered by coin batteries.
I am actually surprised the Apple hardware guys haven't developed a high security SoC just for IofT interfaces.
Ideally encryption is used to protect unspecified data from unknown 3rd parties. However, I'm thinking that a door lock is not sending this, more likely locked or unlocked, basically a known plaintext, which then may make most of encryption susceptible to quicker attacks at obtaining the master key.
Does anyone know if these devices when used with HomeKit, generate their own unique keys or hashes that are associated with commands, that are then encrypted for transmission?
3072 bits is only 384 bytes, not much data. BT LE can handle Mbps speeds, think BT streaming to a cars audio system. The problem is in the amount of work that the encryption/decryption hardware has to perform to obtain a result that is then transmitted via BT in whatever device is used, powered by coin batteries.
I am actually surprised the Apple hardware guys haven't developed a high security SoC just for IofT interfaces.
BT LE does NOT handle Mbps speeds. BT 2.0+EDR does and so does BT 3.0+EDR. LE in BT LE stands for Low Energy, and the primary goal is to have a very low energy consumption, and NOT high speeds. BT LE is designed for very infrequent and small amounts of data, like reading a heart rate monitor. It typically transfers only a few bits or bytes in total, and not kilobytes.
It's been held back by "just good enough is profitable"
The problem isn't Apple here, the problem is that the hardware vendors are choosing to use cheap unreliable parts in the first place.
I'm willing to bet damn near nobody in this forum actually works as trade electrician.
1) Low Voltage != Low Amperage. A typical HVAC or Lighting system has Low Voltage control panels connected to a High Voltage central relay. Some Furnaces that are gas powered, have the controls actually powered by a Pyroelectric generator.
2) You don't want AC power running everywhere, but you don't want a single DC power rail being generated at a central point due to energy losses.
So if you were building a house, from scratch, you would actually want to put all the Low Voltage wiring in parallel to the A/C wiring, but in separately insulated conduits so that any damage to the A/C wiring in the future doesn't short circuit and destroy every LV connected device in a blink of an eye. But you're still forced to rip up your walls to add things. So you won't EVER be doing this in a Condo or Apartment.
Conventional doors (eg the ones that swing open) and Windows (that swing open) have no means of putting power "in the door" without resorting to batteries. If you run power through the hinges, that turns the door into a potential death trap or fire hazard. The correct way to go about this is to actually reverse the position of the door knob and the door latch. Yes... put the door knob and deadbolt into a much thicker frame, and have nothing on the physical door. For Windows, it would require thicker window frames, but the same idea, and I've seen it before on some skylights. You just have an electro-mechanical "scissor lift" that is locked by mechanical resistance when there is no power.
But Bluetooth LE flips the situation around, and instead of running LV wiring everywhere that you can't fix withour ripping up your walls, you can now piece-meal put controls where you need them. So this stuff is primarily targeted at city-dwellers who do not have the option to demolish parts of their units because it would infringe on their neighbors or damage the building environment envelope.
The 3072 bits is not the overall issue. RSA encryption is not a direct conversion from bits to bytes. 3072 is a huge amount of data. Plus it needs to be decrypted on the other end, all very processor intensive not to mention the curves. It is the algorithms of the handshake that causes the lag. I'm getting very tired of responding to people who have no understanding of the actual issues at hand.
According to the wiki BTLE which is a part of Bluetooth smart has OTA 1 Mbit/s and application speed of 0.27 Mbit/s.
https://en.wikipedia.org/wiki/Bluetooth_low_energy
Your comment made it sound like the BTLE communication bandwidth is to small and is the problem, which is not the problem. I agree that it has to do with the processing.
BT LE does NOT handle Mbps speeds. BT 2.0+EDR does and so does BT 3.0+EDR. LE in BT LE stands for Low Energy, and the primary goal is to have a very low energy consumption, and NOT high speeds. BT LE is designed for very infrequent and small amounts of data, like reading a heart rate monitor. It typically transfers only a few bits or bytes in total, and not kilobytes.
According to the wiki BTLE which is a part of Bluetooth smart has OTA 1 Mbit/s and application speed of 0.27 Mbit/s.
https://en.wikipedia.org/wiki/Bluetooth_low_energy
The 3072 bits is not the overall issue. RSA encryption is not a direct conversion from bits to bytes. 3072 is a huge amount of data. Plus it needs to be decrypted on the other end, all very processor intensive not to mention the curves. It is the algorithms of the handshake that causes the lag. I'm getting very tired of responding to people who have no understanding of the actual issues at hand.
In the first post where you seemed to blame throughput rather than processing (I do admit to not reading the article fully so I am at fault for that part). Lunderman said the same thing. Even there, it is basically the fact most companies that use those chips don'T give a crap about encryption that led to them being underpowered in that capacity (chip makers didn't see the point of upping the capabilities of their hardware to serve a non existent need from IOT equipment makers ), so I'm not letting them off the hook regardless.
People have been discussiong the possibly insecurity of the com channels and the net stack in the IOT for several years (at least 3-4) and companies and chip makers should already have had adequate solutions in place to handle this. I know these things a low power and thus cannot be A9... But, they can do better than what they've done up now. Apple basically forced their lazy hands.
Okay, after reading the Forbes article I'm left wondering who mangled whatever information they have, because to be frank, none of these timings are even in the ballpark of what you can do on an off the shelf Bluetooth LE chip. I've actually run some tests (http://github.com/aanon4/HomeKit) on this stuff using a Nordic Bluetooth chip (ARM Cortex-M0 @ 16MHz) and the timings quoted are ridiculous.
The actual HomeKit protocol can be split into two main pieces - pairing (done once) and general control (done often). The pairing on the Nordic chip will take you 40 seconds to complete. It's not fast, but you do it once. This is where you exchange those 3072 bit keys and yes that does seem excessive - but it's entirely doable (and uses an algorithm called SRP developer at Stanford almost 20 years ago). And, as I say, you only do it once. You certainly don't need to do it every time you open a door. Opening a door - the general control piece - uses the Curve25519 algorithm to do a Diffe-Hellman key exchange to establish a unique, per session, shared key between the phone and the device. The reference implementation in C is slow, but it would still only take 10 seconds to open the door - hardly 7 minutes. If you use an optimized version, you're down in the 1-2 second arena (you can probably do better). Also the keys used here are tiny - around 32 bytes - so you're not exchanging large data packets when you're opening the door.
Finally, let's not forget that the Broadcom chips are much more capable than the older Nordic chip on which these numbers are based.
I don't think the problem will be the BTLE data rate. The problem will be the calculations in the key exchange. SRP (the protocol they are using) has a Diffie Hellman like handshake which means the puny computer in your "smart garage door opener" is expected to raise numbers (in this case the number 5) to 256-bit powers, mod a 3072-bit value. That would make even a fast desktop computer pause for a second or two, and makes these little devices pause for tens of seconds.
Perhaps instead they could do one handshake per day (e.g. in the middle of the night) and exchange enough session keys for the whole next day.
Exactly. Forcing stronger encryption makes companies innovate and create better products that help serve them and the consumer. This tech is still in its infancy for the average consumer. Better to get it right than to lead to a bad customer experience, turning consumers away from trusting and using this tech in the future. Especially where home security (door and window locks, security cams etc.) is concerned.
Let's just leave it wide open, so anyone driving past your house can turn the lights on or off...
Have you seen those SmartLocks in the store for your doors? It allows you to easily switch to a new key. They're everywhere, even in locks that work with a App. The only problem is it's mostly plastic inside and using a simple tool you can buy on the internet, Break right in, in the matter of a few seconds!!!! You can see this done on Youtube. These SmartLocks are the ones that have a tiny hole next to where the key is.
According to the wiki BTLE which is a part of Bluetooth smart has OTA 1 Mbit/s and application speed of 0.27 Mbit/s.
https://en.wikipedia.org/wiki/Bluetooth_low_energy
It's true that it can use speeds up to 0.27 Mbps, but that is also an "instant battery drain mode", which is NOT what BLE is intended for.
As I wrote earlier BLE is intended for very small amounts of data, like iBeacon or stuff that you read infrequently like the bathroom scale, or a heart rate monitor. The typical data size is around 10-20 bytes, and it is sent at a low speed to conserve energy.
I have a couple of LightBlue Beans https://punchthrough.com/bean/
If you set them up as iBeacons or some other low-energy application, then the battery lasts for a year or more. The only way to program these is by sending over BLE, so all firmware upgrades and applications I write for them are transferred via BLE. You can only do a few of these program/firmware transfers, before the battery i drained. I can easily drain the battery in a day or two, when using faster transfers.
I bet you don't want to replace your batteries daily, or even weekly. I think you expect your door locks battery to last for at least a couple of months.