[quote]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.[/QUOTE] There are no parts currently available that meet both the vendors specs and Apple security requirements, whether they are cheap and unreliable or not.
Seems like Elgato put together a solution so we may see more products soon. But it is not using off the shelf silicon / software and we don't know the power requirements and cost.
There is quite a bit of misleading to plain wrong information in the article and also in the comments.
HomeKit does not use SSL/TLS.
It's not a hardware issue, but a matter of creating a good software implementation. 40 seconds for opening a connection and reading the lock state is simply a horribly bad implementation.
It's not that 3072 bit keys are transmitted all the time and are slowing things down. 3072 bits are used for SRP, which is typically used once in the lifetime of an accessory, namely when it is set up: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
It's not that most BLE chips on the market are overtaxed by HomeKit security in terms of processor speed. Our implementation (http://oberonhap.com) takes 1.1 seconds for the crypto processing for opening a connection, on a lowly 16 MHz nRF51. Much faster on the newer nRF52.
Our implementation uses less than 12 KB RAM. So on an nRF51 with 32 KB of RAM there is definitely no need for adding external memory.
It's not that 3072 bit keys are transmitted all the time and are slowing things down. 3072 bits are used for SRP, which is typically used once in the lifetime of an accessory, namely when it is set up: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
Are you sure? I thought HomeKit did a fresh SRP handshake for each transaction, in order to achieve perfect forward secrecy.
Are you sure? I thought HomeKit did a fresh SRP handshake for each transaction, in order to achieve perfect forward secrecy.
Yes, SRP is only performed for setup, for the exchange of long-term keys. Perfect forward secrecy is established later, whenever a connection is opened, using session keys.
Yes, SRP is only performed for setup, for the exchange of long-term keys. Perfect forward secrecy is established later, whenever a connection is opened, using session keys.
Ok thanks. I don't know why it's so slow then, it must be, as you say simply poor implementation. Maybe their modExp is slow (as used in the DH-like session key exchange).
Comments
The problem isn't Apple here, the problem is that the hardware vendors are choosing to use cheap unreliable parts in the first place.[/QUOTE]
There are no parts currently available that meet both the vendors specs and Apple security requirements, whether they are cheap and unreliable or not.
Seems like Elgato put together a solution so we may see more products soon. But it is not using off the shelf silicon / software and we don't know the power requirements and cost.
HomeKit does not use SSL/TLS.
It's not a hardware issue, but a matter of creating a good software implementation. 40 seconds for opening a connection and reading the lock state is simply a horribly bad implementation.
It's not that 3072 bit keys are transmitted all the time and are slowing things down. 3072 bits are used for SRP, which is typically used once in the lifetime of an accessory, namely when it is set up: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
It's not that most BLE chips on the market are overtaxed by HomeKit security in terms of processor speed. Our implementation (http://oberonhap.com) takes 1.1 seconds for the crypto processing for opening a connection, on a lowly 16 MHz nRF51. Much faster on the newer nRF52.
Our implementation uses less than 12 KB RAM. So on an nRF51 with 32 KB of RAM there is definitely no need for adding external memory.
Could you be more specific regarding "vendor specs" that are not met?
As for the Apple requirements: a HomeKit SDK by Nordic Semiconductor for their nRF51 has been approved by Apple (http://www.nordicsemi.com/eng/News/News-releases/Product-Related-News/Nordic-Semiconductor-launches-HomeKit-solution-for-nRF51-Series-Bluetooth-Smart-SoCs), it is based on our OberonHAP code (http://oberonhap.com). The new nRF52 is several times as fast and definitely also meets the requirements. Then there are chips of about half a dozen other vendors that probably meet the requirements as well.
It's not that 3072 bit keys are transmitted all the time and are slowing things down. 3072 bits are used for SRP, which is typically used once in the lifetime of an accessory, namely when it is set up: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
Are you sure? I thought HomeKit did a fresh SRP handshake for each transaction, in order to achieve perfect forward secrecy.
Are you sure? I thought HomeKit did a fresh SRP handshake for each transaction, in order to achieve perfect forward secrecy.
Yes, SRP is only performed for setup, for the exchange of long-term keys. Perfect forward secrecy is established later, whenever a connection is opened, using session keys.
Yes, SRP is only performed for setup, for the exchange of long-term keys. Perfect forward secrecy is established later, whenever a connection is opened, using session keys.
Ok thanks. I don't know why it's so slow then, it must be, as you say simply poor implementation. Maybe their modExp is slow (as used in the DH-like session key exchange).