Алгоритм обмена ключами LoRaWAN, судя по даташиту, не должен работать

Изучаю протокол связи LoRaWAN по даташиту LoRaWAN 1.0.3 Specification. В шифровании сообщений используется 3 ключа: AppKey, AppSKey, NwkSKey. Смотрим определение первого из них.

The AppKey is an AES-128 root key specific to the end-device. Whenever an end-device joins a network via over-the-air activation, the AppKey is used to derive the session keys NwkSKey and AppSKey specific for that end-device to encrypt and verify network communication and application data.

То есть это ключ, который прошит в каждое конкретное устройство и известно только ему. Далее описывается процедура обмена ключами AppSKey и NwkSKey. Сначала отправляется запрос на присоединение, содержащий идентификатор приложения, идентификатор устройства и случайное число DevNonce. Код целостности этого сообщения рассчитывается так:

MIC = aes128_cmac(AppKey, ПОЛЯ_СООБЩЕНИЯ | DevNonce)[0..3]

Сразу же возникает вопрос: как сетевой сервер сможет проверить код целостности пакета, если он не знает AppKey? В даташите нет ни одного упоминания о том, что AppKey должен быть известен сетевому серверу. Рассчитать ключ по исходному сообщению и коду контроля целостности сервер не сможет - иначе сеть была бы уязвима к атакам.

Следующим сообщением сетевой сервер отправляет устройству ответ на присоединение, которое само по себе зашифровано ключом AppKey, и его код целостности рассчитывается с использованием AppKey. Так откуда сетевой сервер должен его узнать?

Если предположить, что сетевой сервер хранит таблицу соответствия "устройство - ключ", то возникает угроза его компрометации. И каким образом эта таблица должна составляться? А процедуру смены ключа даташит не описывает.

В общем, прошу объяснить, что представляет из себя этот ключ, кто его должен назначить - производитель устройства или администратор сети, и если администратор сети - то каким образом он должен его записать в устройство и сетевой сервер.