Internet of Things Stack Exchange is a question and answer site for builders and users of networked sensors and control devices in the contexts of smart homes, industry automation, or environmental sensors. It only takes a minute to sign up.
Sign up to join this community
In the LoRaWAN 1.1. standard it says on Page 16 "For Join-Accept frame, the MIC field is encrypted with the payload and is not a separate field".
In other scenarios the message integrity code is a separate field, so the message is encrypted, before the MIC is generated, if I understood this correctly. It is considered to be more secure to use Encrypt-then-MAC.
Do you have an idea why MAC-then-encrypt is used for this message type?
In case of all LoRaWAN messages, except JoinAccept, the MIC must be accessible by interim network components, like forwarding network server who know the NwkSKey and can verify message integrity and drop the message if it fails.
However, interim network elements should have no information about the integrity of a JoinAccept message. This is to increasing the level of security.
If someone knew the MIC of a JoinRequest, then he could guess an AppKey/JoinNonce and check if they are correct programmatically. If that guy invests in a large computer farm and operates that network for a long time, he may find out what the AppKey is. It is not possible if MIC is not accessible.
You may say that that bad guy can do the same for regular uplink messages. That is true, but please note that UL messages are signed and encripted by session keys and not by the master key.
