cpu/esp_common: change esp_now key param

[gschorcht]

Contribution description

This PR changes the way the 128-bit key for encrypted ESP-NOW communication is defined.

The 128-bit key for encrypted ESP-NOW communication is defined by a 16-byte array of type uint8_t [16] specified by the ESP_NOW_KEY configuration parameter in RIOT. By default, this configuration parameter is specified as NULL (no encryption). While it easy to define the key as static initializer in C

#define ESP_NOW_KEY { 0x0f, 0x1e, ... }

it is not possible to define such static initializer in Kconfig. Therefore, in regard to the migration to Kconfig, the key is now defined as a string with hex values separated by spaces

#define ESP_NOW_KEY "0f 1e ..."

which is easy to implement in Kconfig.

The documentation is updated accordingly as well as fixed and improved a bit.

The PR includes the fix in PR #17420 (commit 87a72e4) which is skipped once PR #17420 is merged and this PR is rebased.

Testing procedure

1. Set ENABLE_DEBUG in cpu/esp_common/esp_now_netdev.c.
2. Compile and flash example/gnrc_networking for two nodes as follows:

   CFLAGS='-DESP_NOW_KEY=\"0f\ 1e\ 2d\ 3c\ 4b\ 5a\ 69\ 78\ 87\ 96\ a5\ b4\ c3\ d2\ e1\ f0\"' \
   make BOARD=esp32-wroom-32 -C examples/gnrc_networking PORT=/dev/ttyUSB<0|1> flash term
   

3. Once the nodes have found each other and are connected, the output should look something like this.

   _esp_system_event_handler WiFi scan done
   wifi_scan_get_ap_num ret=0 num=2
   wifi_scan_get_aps ret=0 num=2
   esp_now_key: 0f 1e 2d 3c 4b 5a 69 78 87 96 a5 b4 c3 d2 e1 f0
   esp_now_add_peer node 30:ae:a4:41:60:f9 added with return value 0
   associated peers total=1, encrypted=1
   

4. Ping the node from one node (optional), e.g.

   ping6 fe80::32ae:a4ff:fe41:60f9
   

   In this example the LLUA is used as generated from the MAC address that was given in the output in step 3:

   esp_now_add_peer node 30:ae:a4:41:60:f9 added with return value 0
   

Issues/PRs references

Depends on PR #17420

[benpicco]

I guess we could also handle this like IEEE802154_SEC_DEFAULT_KEY and just use a string in KConfig, but allow for a byte array to be supplied via the Makefile.

(I also assume this has the same issues wrt. key exchange as IEEE 802.15.4 security - #16844 They could probably use a common upper layer solution)

[gschorcht]

I guess we could also handle this like IEEE802154_SEC_DEFAULT_KEY and just use a string in KConfig, but allow for a byte array to be supplied via the Makefile.

But defining it as a string reduces the possible entropy a lot. The solution in this PR would allow to use the value range. OK, it makes the definition a bit more difficult, but not too much.

[benpicco]

Ok, but why the spaces? A hex byte is unambiguous with two characters, no need to separate them with spaces.
We could then also use that hex string to byte array method for the 802.15.4 security module

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[gschorcht]

I will continue to work on this in next few week.