Is it possible to save the bonding keys to retention RAM instead of EEPROM, thus avoiding the need for EEPROM in a very simple application?
是there library functions to do this? If not, what is involved?
Thanks,
Tom
Keywords:
Device:
Yes but then you will lose them when you reboot the chip, but I assume you are aware of that.
The simplest way is to just store them in a variable with the attribute
__attribute__((section("retention_mem_area0"),zero_init)).You should store them as pairs of ((rand_nb, ediv), (ltk, ltk_length)). Maybe also include the mac address or irk in the key. Have an array where you can store multiple pairs.
The flow is the following:
The function app_send_ltk_exch_func will be called when an ltk should be generated. This function calls app_sec_gen_ltk which generates a random key. (Note that the default implementation uses the pseudo number generator rand() that only uses a 32-bit seed. If you want to be secure, you should use the new trng api instead). The key size is at least 7 bytes and at most 16 bytes. This key is stored in app_sec_env, which is later sent to the master.
It is in the function app_paired_func you should store the app_sec_env.rand_nb, app_sec_env.ediv, app_sec_env.ltk and app_sec_env.key_size values to your permanent store (for example EEPROM or in your case retention ram).
You then need to do the lookup in app_validate_encrypt_req_func by using the values param->rand_nb and param->ediv. If you find a match in your permanent store, write the values to app_sec_env.rand_nb, app_sec_env.ediv, app_sec_env.ltk and app_sec_env.ltk_size, and return true. Else return false.
Please note that the "just works" version of the pairing mechanism is insecure if the air traffic is sniffed by someone during pairing since the long term key is sent in plaintext over the air (but only during the pairing phase), so avoid that mode if possible.
You can also look at the keyboard reference source, in app_kbd_proj.c how these functions are implemented. You might also want to read the comment "We may reach this point after getting an LL_ENC_REQ from an unbonded host with EDIV and RAND set to zero. Reject the Host in case of MITM since no Pairing has been perfomed." and the code after in app_paired_func.
Note that by default the latest key is always stored in app_sec_env (which is in retention ram) and app_validate_encrypt_req_func by default only returns true, so if you only make connections to one device, the correct ltk will always be loaded.
It looks like one could replace the eeprom calls in multibond with similar calls to write retention ram. Is there a simpler implementation which only allows a single bond?
I would think that many BLE applications require bonding (heart rate, keyboard, remote control, etc). Having to add a EEPROM somewhat defeats the simplicity of using the internal OTP. If I use the keyboard app as an example and a large EEPROM, is there any reason I can't store code and keys in it by relocating the keys to high memory? Might be better to go with SPI flash and reserve two pages for keys (to allow copying from one page to another if mulibond is needed).
Thanks,
Tom
Neither the flash nor eeprom can be memory mapped on the da14580 as far as I know. So you need to use the driver code to write or read external memory. The otp is one time programmable, so you can't store bonding keys in it.
If I use external SPI flash to store the code (no use of OTP), is there any reason that I would not be able to also store the bonding keys there? I would reserve a page or two of flash and modify the the multibond code.
Hi tcrussell,
You can use the SPI in order to store the bonding keys in the SPI flash. The keyboard application implements this with an EEPROM memory.
Thanks MT_dialog