AES128 Encryption on LoRa - Thoughts?

[kd8bxp]

Any thoughts on LoRa using AES Encryption? http://www.semtech.com/wireless-rf/internet-of-things/what-is-lora/ https://www.lora-alliance.org/what-is-lora https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-LoRa-security-guide-1.2-2016-03-22.pdf I've been looking for a way to turn it off, but it looks to me like even when no specified there is a key pair exchange.

Any thoughts on this and using it as a ham?

[mfalkvidd]

LoRa does not require encryption. loraham does not use encryption (encryption is not allowed for ham). You might be confusing LoRaWAN with LoRa?

[kd8bxp]

I am aware hams can't use encryption, can you give me a link where it says LoRa doesn't use encryption? What I am not seeing is that it uses AES128, and I can't find away to turn it off. Yes, I admit the terms LoRa and LoRaWan do cause problems, and I understand they are different. I don't think I have confused the two, but I maybe wrong.

[mfalkvidd]

Sorry, proving a negative is kind of hard.

[travisgoodspeed]

LoRaHam does not use AES128 or any other form of cryptography. Closing issue.

[kd8bxp]

Section 3 of https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-LoRa-security-guide-1.2-2016-03-22.pdf 3.1 Joining a Node to a LoRa network 3.1.1 Over-The-Air-Activation (OTAA) The first method by which Nodes are allowed to join a LoRa network is through OTAA. Here each Node is deployed with a unique 128-bit app key (AppKey) which is used when the Node sends a join-request message. The message is not encrypted, but is signed using this AppKey. The Node sends the join-request message including its unique AppEUI and DevEUI values plus a DevNonce which should be a randomly generated two byte value. The AppEUI should be unique to the owner of the device. The DevEUI should be a globally unique identifier for the device. These three values are signed with a 4 byte MIC which is produced using the following calculation: mac=aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce) MIC = mac[0..3] The server should check the values and then re-calculate the MIC with the AppKey. If valid, the server may respond with a join-accept message within the receive windows of the Node. The Network server generates its own nonce value (AppNonce) and calculate the Node’s two new 128-bit keys: the app session key (AppSKey), and the network session key (NwkSKey). These are calculated based on the values sent to it in the join-request message: NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16) The join-accept reply includes an AppNonce, an end-device address (DevAddr) along with configuration data for RF delays (RxDelay) and channels to use (CFList). A MIC is generated using the following calculation: mac = aes128_cmac(AppKey, MHDR | AppNonce | NetID | DevAddr | RFU | RxDelay | CFList) MIC = mac[0..3] This data is sent back using the AppKey as an encryption key. In this way, the Node can use the AppKey to decrypt the data and then calculate AppSKey and NwkSKey key using the AppNonce. 3.1.2 Activation by Personalisation (ABP) ABP differs from OTAA as the Nodes are shipped with the DevAddr and both session keys (NwkSKey and AppSKey), which should be unique to the Node. As the Nodes already have the information and keys they need, they can begin communicating with the Network Server without the need for join messages. labs.mwrinfosecurity.com 73.2 Protection of data sent over LoRa networks Once a Node has joined a LoRa network, either through OTAA or ABP, all future messages will be encrypted and signed using a combination of NwkSKey and AppSKey. As these keys are only known by the Network Server and specific Node, there should be no way for another Node, or a man in the middle attack to recover the clear-text data. 3.2.1 Data Encryption Encryption of messages is performed using AES128 in Counter mode (CTR). If the packet’s FPort is set to 0 then the NwkSKey is used, otherwise the AppSKey is used. An important feature of all messages in LoRa is that the counters for sent (FCntUp) and received (FCntDown) messages are maintained by the

SO to me it looks like it is using AES128, all I asked was for some documentation that says either how to turn of AES or that it doesn't use it at all. I am not trying to be difficult, I do want to stay legal, and I'm not sure after I found this document.

[voteblake]

MWR's report is sloppy in this regard.

All references to LoRa in the section you pasted in can only be applied to LoRaWAN and are not at all parts of LoRa itself.

This project only uses LoRa and does not have all of the complexity of LoRaWAN, including the uses of cryptography mentioned in the MWR report.

On Sun, Sep 17, 2017 at 13:32 LeRoy Miller notifications@github.com wrote:

Section 3 of https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-LoRa-security-guide-1.2-2016-03-22.pdf 3.1 Joining a Node to a LoRa network 3.1.1 Over-The-Air-Activation (OTAA) The first method by which Nodes are allowed to join a LoRa network is through OTAA. Here each Node is deployed with a unique 128-bit app key (AppKey) which is used when the Node sends a join-request message. The message is not encrypted, but is signed using this AppKey. The Node sends the join-request message including its unique AppEUI and DevEUI values plus a DevNonce which should be a randomly generated two byte value. The AppEUI should be unique to the owner of the device. The DevEUI should be a globally unique identifier for the device. These three values are signed with a 4 byte MIC which is produced using the following calculation: mac=aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce) MIC = mac[0..3] The server should check the values and then re-calculate the MIC with the AppKey. If valid, the server may respond with a join-accept message within the receive windows of the Node. The Network server generates its own nonce value (AppNonce) and calculate the Node’s two new 128-bit keys: the app session key (AppSKey), and the network session key (NwkSKey). These are calculated based on the values sent to it in the join-request message: NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16) The join-accept reply includes an AppNonce, an end-device address (DevAddr) along with configuration data for RF delays (RxDelay) and channels to use (CFList). A MIC is generated using the following calculation: mac = aes128_cmac(AppKey, MHDR | AppNonce | NetID | DevAddr | RFU | RxDelay | CFList) MIC = mac[0..3] This data is sent back using the AppKey as an encryption key. In this way, the Node can use the AppKey to decrypt the data and then calculate AppSKey and NwkSKey key using the AppNonce. 3.1.2 Activation by Personalisation (ABP) ABP differs from OTAA as the Nodes are shipped with the DevAddr and both session keys (NwkSKey and AppSKey), which should be unique to the Node. As the Nodes already have the information and keys they need, they can begin communicating with the Network Server without the need for join messages. labs.mwrinfosecurity.com 73.2 Protection of data sent over LoRa networks Once a Node has joined a LoRa network, either through OTAA or ABP, all future messages will be encrypted and signed using a combination of NwkSKey and AppSKey. As these keys are only known by the Network Server and specific Node, there should be no way for another Node, or a man in the middle attack to recover the clear-text data. 3.2.1 Data Encryption Encryption of messages is performed using AES128 in Counter mode (CTR). If the packet’s FPort is set to 0 then the NwkSKey is used, otherwise the AppSKey is used. An important feature of all messages in LoRa is that the counters for sent (FCntUp) and received (FCntDown) messages are maintained by the

SO to me it looks like it is using AES128, all I asked was for some documentation that says either how to turn of AES or that it doesn't use it at all. I am not trying to be difficult, I do want to stay legal, and I'm not sure after I found this document.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/loraham/issues/18#issuecomment-330081738, or mute the thread https://github.com/notifications/unsubscribe-auth/AFU8JT1iwQcZ8CvBsAdksJ0p9BksgZ3rks5sjYHngaJpZM4PaPF- .

[PA2PIM]

Hi, a bare bone Semtech SX127x LORA chip such as found on various RFM95 and similar modules does not have encryption. See the datasheet at http://www.semtech.com/images/datasheet/sx1276.pdf. That is what LoraHam is using. Now the Microchip RN2483 modules for example implemented LoraWan and you might be right that on these modules you can not turn encryption off. 73 PA2PIM

[kd8bxp]

@voteblake I am finding a lot of sloppy information in terms of inter-changing LoRa for LoRaWAN. And I do understand that they are really two different things. And that LoRaWAN is built on top of LoRA - but it does lead to a lot confusion. @PA2PIM Thank you, that document is what I've been looking for. I will spent some time reading it. Hopefully it clears up some of the confusion. @mfalkvidd I think I have confused the two.