I need to use Eddystone EID in order to use rotatated eid. I’ve follow the instruction by using nRF Beacon for Eddystone with dfu 1.3.4, 1.3.5 and 1.3.6 but I always get Error 133 occurred. Then the application was disconnected from Ruuvi Tag and then I get another error “Error 8 occurred”. Only 1 tag from 4 tags can be configure as Eddystone EID.
I can repeat the issue with ECDH key. EID key seems to work. Can you use the EID key for now, I’ll check if the issue with ECDH is present on Nordic semi dev kit.
The EID key option does work. What is the different between ECDH key and EID key? For me, ECDH key is quite standard, but I cannot find document regarding EID key else where. It’d be great if you can give me some information regarding EID key.
I think the ECDH is used for the provisioning process by Google’s beacon tools, and both methods end up with a rotating key. However I’ve only a little experience with the Eddystone so I’m not certain.
I’ll follow-up tonight on the ECDH on Nordic development kit, maybe this is ECDH is something we can fix in our Eddystone firmware
The ECDH works on Nordic dev kit / example software, the issue seems to be that our Eddystone cannot transfer the keys over BLE during provisioning. We’ll have this issue fixed soon.
Thank you for promptly response. I’m looking forward for the fw update.
I followed instructions too with DFU 1.3.6 but I had the same error when configuring EID on my RuuviTag with NRF beacon for eddystone. But EID key security type is working. With this security, the identity key is still computed inside the RuuviTag, right? So, which public keys are used in this case to generate the IK?
I built my own resolver, its not possible to register a beacon with EID key security ?
Sorry for the delay. Please try Eddystone 2.3.0, available at https://drive.google.com/open?id=1jX0c7oNOehn_qWxha36urjEIkeObu5vQ .
It has buttonless DFU service and DIS service disabled, but EID key exchange seems to work as expected.
If it works for you we’ll update the release.
We flashed over the air DFU 2.3.0. Then with Android app we configured the beacon as EID one with Public ECDH exchange (the recommended one) and with an exponent of 10. Everything worked fine!! Thank you for this update of the DFU. While doing this setup, we were also sniffing BLE packets. However the stuff is working, we noticed in the captured packets that at the end, the android app is requesting and receiving the encrypted IK from the EID beacon. This is so strange because with the two public key the phone can re compute the IK from his side. Is there any reasons? (like only displaying the IK for the user?)
Thanks you in advance,
The Android app and Eddystone service are implemented by Nordic Semiconductor, they would have the best knowledge to answer your question.
OK i understand. So i would like to disable the MAC randomize and use ECDH. But the lastest DFU available on ruuvitag_fw repo is 1.3.6. is it possible to share with us dfu 2.3.0 source code?
The code is in this pull request: https://github.com/ruuvi/ruuvitag_fw/pull/130
The package is currently in our QC process, if no issues are found I’ll merge the sources and update the packages.
For your reference, here is the power profile on + 0dBm 2 Hz Eddystone URL:
Ok great. I will take a look.
Thanks for everything
After more test of DFU 2.3.0, we noticed that everytime we set a slot to EID frame type and then switch this to an UID frame type, after some time, this same slot turns by himself into an EID one again. This is really strange.
So basically, what we are doing:
- set up beacon as eddystone EID
- capture and check thats everything is fine (it is, capturing EID key and other stuff)
- change same slot to eddystone UID
- capture and check thats everything is fine (it is, capturing namespace and instance fields)
- wait for around 10-15min (strangely the exponent rotation set before) and then packets captured are eddystone EID packets
Do you have Ruuvi devkit or nRF52-DK? You could try the SDK15 Eddystone to see if this issue has been fixed, or I can try to replicate the issue on my end tomorrow.
Yes we have both. We tried with nRF52-DK using SDK-15 Eddystone. We tried to re-produce the same bug by configuring the beacon as EID then UID: the resukt is the same, beacon goes back to EID type after some time (approx 5min).
We’ll need to report this to Nordic Semiconductor and see if they would have a fix available. Would you like to be CC’d in the emails?
Yes, I would like.
I reported the issue onwards. While replicating I also found a workaround: If the tag is reset after the configuration, the UID will not rotate.
On our side, we already experienced this previously. By reset, you mean factory reset, right?