This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

gzll keycode (optional host id validation stage)

To the kind attention of Nordic support team,

I'm interested in implementing some sort of validation stage using a keycode, as you mention in:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Fgzp_02_user_guide.html&cp=7_5_0_5_4_3&anchor=key_ex_stages

Is there something you can share so to better understand how this can be achieved the best way?

Some implementation that you know about and could be as a starting point?

Any relevant documentation/idea about this subject, please?

Thank you very much for your attention and your help

Best regards

Parents
  • Hi Stella

    We don't have any examples showing how to use the authentication feature in GZP unfortunately. 

    In general, if security is important to you I would greatly recommend using BLE instead of Gazell/GZP. 

    The GZP pairing and encryption library is quite outdated at this point, and is not very secure. For instance the system is based on a pre-programmed  secret key which is shared between all the systems, so if a hacker manages to break one device and find this key they will get access to all the devices. 

    Best regards
    Torbjørn

  • Hi ovrebekk thank you very much for your reply, it is very interesting. We have got the requirement to both use BLE and gzll protocol. We are thinking, related to what you said, to modify the open code of gzp, so to implement an ECDH key-exchange first (maybe over gzp pipe0), for replacing the pre-programmed secret key. Is it feasible in your opinion? In theory we want to replicate over the air what you have in your sdk crypto folder, and then get a brand new key to use in place of the pre-programmed one. Based on your experience does it seem feasible to you? And you see any problem in this approach? Thank you very much

Reply
  • Hi ovrebekk thank you very much for your reply, it is very interesting. We have got the requirement to both use BLE and gzll protocol. We are thinking, related to what you said, to modify the open code of gzp, so to implement an ECDH key-exchange first (maybe over gzp pipe0), for replacing the pre-programmed secret key. Is it feasible in your opinion? In theory we want to replicate over the air what you have in your sdk crypto folder, and then get a brand new key to use in place of the pre-programmed one. Based on your experience does it seem feasible to you? And you see any problem in this approach? Thank you very much

Children
Related