Protection for LoRaWAN security keys in EEPROM #121
Description
Related commit: 1bd604a
This is an interesting idea, but as currently implemented this would only provide minimal (accidental) protection. As long as you have access to USART1, USART2, or SPI interfaces, which all devices that I have seen have to support firmware updates, you can always access the keys stored in EEPROM. The application could flash a modified version of the firmware into the modem, or even just an older version of this firmware. Another method is to switch into the STM32 bootloader and read the EEPROM from there.
Also, the AppKey is only used in the OTAA mode to derive the AppSKey. In the APB mode, the modem directly uses the AppSKey. Since we support both modes in the firmware, we would need to lock both keys.
It might be a good idea to think about how we could provide more protection for the various LoRaWAN security keys. Perhaps we could keep the keys in EEPROM encrypted with a key encryption key (KEK) and, e.g., AES-SIV [1]. The modem would then be provided with the KEK, to only store in SRAM, on boot. We should also think about the threat model, i.e., what we would want to protect against.
Encrypting LoRaWAN security keys with a KEK might be interesting in designs where the Type ABZ module is replaceable such as the Hardwario Tower kit. There, one might want to prevent key extraction from a Type ABZ module that has been physically removed from the device. If the attacker has access only to the Type ABZ module and not to the host MCU, they would be unable to decrypt the keys. Perhaps it might also be useful to prevent another Core Module (host MCU) from using an already configured (joined) Type ABZ module, unless it has the KEK. Related: #72.
In designs where the TypeABZ module is hard-wired to the host MCU, encrypting LoRaWAN security keys stored in EEPROM with a KEK makes little sense. The host MCU would have to have access to the KEK in order to send it to the TypeABZ module. The attacker would always have access to both the host MCU and the Type ABZ module. Thus, they could (presumable) extract the KEK and decrypt the contents of Type ABZ's EEPROM.
If the host MCU had some kind of secure element, i.e., a place to securely store LoRaWAN keys, we could, in theory make the firmware in the Type ABZ module use that. This would require a simple protocol to delegate AES operations from Type ABZ to the host MCU.
Originally posted by @janakj in #117 (comment)
CC: @disk91