A Multiple End-Devices Authentication Scheme for LoRaWAN
Round 1
Reviewer 1 Report
In the introduction, too much attention is paid directly to the standards and protocols of the Internet of things. Not enough attention to the problem of a large number of things and authentication problems, no references to the sources of the problem, lines 75-77.The Preliminaries also mainly talks about the protocol itself. There is not enough work on the topic of authentication. The problem is clear and relevant, but it still needs to be proved and similar schemes considered. It is clear that the protocol itself uses a certain scheme, but there are certainly other studies to improve it. In order to highlight the advantages of your scheme, you need to point out the shortcomings of the existing ones.As I understand it, aes 128 is used for encryption, why is this one chosen? Why not 256, it's more reliable, why not lightweight cryptography?No explanation is given on how the secret key is generated, the key distribution scheme is not very flexible in my opinion.Are the performance advantages achieved only through the multiprocessor approach?
Here are some offhand publications on a similar topic. Perhaps you have a different line of research, but it is worth considering other works.
A Secure and LoRaWAN Compatible User Authentication Protocol for Critical Applications in the IoT Environment | IEEE Journals & Magazine | IEEE Xplore
A Lightweight Blockchain Based Two Factor Authentication Mechanism for LoRaWAN Join Procedure | IEEE Conference Publication | IEEE Xplore
Secure Session Key Generation Method for LoRaWAN Servers | IEEE Journals & Magazine | IEEE Xplore
A Fast Session Key Generation Scheme for LoRaWAN | IEEE Conference Publication | IEEE Xplore
Authentication by RSSI-Position Based Localization in a LoRa LPWAN | IEEE Conference Publication | IEEE Xplore
Author Response
Answers to Reviewer 1
Comment R1.1: In the introduction, too much attention is paid directly to the standards and protocols of the Internet of things. Not enough attention to the problem of a large number of things and authentication problems, no references to the sources of the problem, lines 75-77.
Response to R1.1: We are thankful for your valuable suggestion. The revised manuscript mentioned a detailed illustration of authentication problems and revised the Introduction section thoroughly. Besides, we reference the statement on lines 75-77.
Comment R1.2: The Preliminaries also mainly talks about the protocol itself. There is not enough work on the topic of authentication.
Response to R1.2: We are very thankful for your valuable suggestion. As advised, we have introduced more recent related authentication works in the revised manuscript.
Comment R1.3: The problem is clear and relevant, but it still needs to be proved and similar schemes considered. It is clear that the protocol itself uses a certain scheme, but there are certainly other studies to improve it. In order to highlight the advantages of your scheme, you need to point out the shortcomings of the existing ones.
Response to R1.3: We are very thankful for your insightful observations. We enhanced the manuscript organization and mentioned the possible limitations of the existing works and the advantages of the proposed authentication protocol. Besides, we mentioned why and how the proposed achieved specific security features during authentication in the revised manuscript. Some of the advantages of the proposed scheme are listed below:
- The proposed scheme supports LoRA specifications with minimal modification in scheme construction.
- The suggested technique allows several end-devices of the same gateway to generate group keys. Supporting group key creation may be helpful for future applications because end devices from the same gateway may have specific correlations. Furthermore, each end-device requires one additional hash operation.
- Under a formal security model, the suggested technique is protected against known attackers. Moreover, it defends attacks against fake end-devices, network servers, and session keys.
- While multi-end-device authentication is considered, the suggested technique saves overall execution time by around 33% compared to the LoRA Specification
Comment R1.4: As I understand it, aes 128 is used for encryption, why is this one chosen? Why not 256, it's more reliable, why not lightweight cryptography?
Response to R1.4: We are very thankful for your valuable comment. The proposed protocol considered AES-128 to provide authentication. However, there is no strict necessitate of using AES-128; we may use AES 256 to provide higher security, according to the LoRa Alliance [1]. During the scheme construction, we focused on providing maximum security features with minimal usage of cryptographic primitive. We have included some remarks in the revised manuscript based on the suggestion.
[1] https://lora-alliance.org/wp-content/uploads/2020/11/lorawan_security_whitepaper.pdf
Comment R1.5: No explanation is given on how the secret key is generated, the key distribution scheme is not very flexible in my opinion. Are the performance advantages achieved only through the multiprocessor approach?
Response to R1.5: We are very thankful for your remarkable observations. We mainly focus on secure authentication with the help of symmetric key cryptography. The key distribution mechanism is slightly different than other approaches. Here, we assumed that the manufacturer installed the respective keys while purchasing end-devices prior to the deployment. These keys are safely stored on the private part of such devices.
Comment R1.6: Here are some offhand publications on a similar topic. Perhaps you have a different line of research, but it is worth considering other works.
- A Secure and LoRaWAN Compatible User Authentication Protocol for Critical Applications in the IoT Environment | IEEE Journals & Magazine | IEEE Xplore
- A Lightweight Blockchain Based Two Factor Authentication Mechanism for LoRaWAN Join Procedure | IEEE Conference Publication | IEEE Xplore
- Secure Session Key Generation Method for LoRaWAN Servers | IEEE Journals & Magazine | IEEE Xplore
- A Fast Session Key Generation Scheme for LoRaWAN | IEEE Conference Publication | IEEE Xplore
- Authentication by RSSI-Position Based Localization in a LoRa LPWAN | IEEE Conference Publication | IEEE Xplore
Response to R1.6: We are very thankful to the reviewer for providing related works helpful in enhancing the quality of the manuscript. As suggested, we have studied and suitably discussed with their possible limitations in the revised manuscript.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
Thanks for the submission.
Here are some questions/comments from my side:
- Fig. 2: The figure itself is right, but what ranges do you have in mind for the axes? High/Low/short/long - Further check the existing publications to this topic as I have the feeling I know it from other ones. Just ensure that no plagiarism applies
- page 3 line 102: use same naming throughout the paper: diagram 3--> Figure 3
- page 3 line 103: here you need to end with ":" and add a reference, as the mentioned things are not yours.
- Section 2.2. requires a reference as this all is not your output, it stands in the classic LoRa documentation
- Reading Section 4 is interesting, but hard to understand as I am not an math expert. What is the benefit of your proposed solution. It seems to me as you blow up the standard or reveal secret things from the standard that is not meant to be public.
- Looking into Section 5 I must say, that I cannot trust the stated words, as I do not find details about the evaluation and your proof process.
Author Response
Answers to Reviewer 2
Comment R2.1: Fig. 2: The figure itself is right, but what ranges do you have in mind for the axes? High/Low/short/long - Further check the existing publications to this topic as I have the feeling I know it from other ones. Just ensure that no plagiarism applies.
Response to R2.1: We are very thankful for your valuable observations. According to the LoRa Development Portal [1], the range provided by LoRa can be up to five kilometers and fifteen kilometers in urban areas and rural areas, respectively. The terms High and Low for the bandwidth axis in Fig 2 could be 40MHz and 150KHz, respectively. On the other hand, short and long for the range axis 50 meters and 10 kilometers, respectively. As advised, we revised the figure with more description in the revised manuscript.
[1] "What are LoRa® and LoRaWAN®?". LoRa Developer Portal. Retrieved 7 July 2021.
Comment R2.2: page 3 line 102: use same naming throughout the paper: diagram 3--> Figure 3
Response to R2.2: We are thankful for your suggestion. On line 120 of page 4, we updated “diagram 3” to “Figure 3”. Besides, we thoroughly revised the manuscript for similar mistakes.
Comment R2.3: page 3 line 103: here you need to end with ":" and add a reference, as the mentioned things are not yours.
Response to R2.3: We are thankful for your suggestion. As recommended, we have updated line 120 of page 4 as:
- “Figure 3 depicts an overview of the LoRaWAN architecture. The entities defined in the LoRaWAN architecture are described below [13]:”
Besides, we thoroughly revised the manuscript for similar mistakes.
Comment R2.4: Section 2.2. requires a reference as this all is not your output, it stands in the classic LoRa documentation
Response to R2.4: We are very thankful for the suggestion. In Section 2.2 of the revised manuscript, we cited classic LoRa adequately.
Comment R2.5: Reading Section 4 is interesting, but hard to understand as I am not an math expert. What is the benefit of your proposed solution. It seems to me as you blow up the standard or reveal secret things from the standard that is not meant to be public.
Response to R2.5: We are very thankful for your valuable comment. The proposed technique achieved certain security features, such as multi-device mutual authentication, data integrity, resistance against session key disclosure, and strong protection against fake end-devices and fraudulent servers. We believe that formal security proofs are better accepted than informal security claims. Thus, we proved that the scheme achieves specific security properties through the mathematical reduction in the standard security model.
Comment R2.6: Looking into Section 5 I must say, that I cannot trust the stated words, as I do not find details about the evaluation and your proof process.
Response to R2.6: We are very thankful for your valuable comment. In Section 5, we compare the proposed scheme with the LoRaWAN standard regarding security properties with adequate computation costs. We show that the proposed protocol achieves additional multiple end-device authentication. Besides, we executed cryptographic operations on the specified configured device and estimated the proposed protocol's overhead. The proposed protocol supports more security features and shows their formal proofs with adequate computation overhead, thus, it could be considered a better approach than others.
Author Response File: Author Response.pdf
Reviewer 3 Report
Summary
In this paper, the authors suggest an authentication approach and mechanism for the end-device join session to the LoRaWAN network.
The proposed scheme is claimed to be more efficient than the one on the LoRa Standard in terms of join latency. In addition, the authors assessed the authentication overhead and compare it to the standard approach in scenarios of 50, 100 and 1,000 end-devices. These figures represent the typical densities in LoRaWAN networks and the maximum number of end-devices in such networks.
The proposed authentication system was assessed formally and is secure against the server and end-device impersonation.
Major Comments
List some limitations of the proposed scheme as compared to the literature, not necessary to the standard.
Finally, list some open research challenge to be leveraged in further studies
L379. Is 1000 the limit for a network per gateway?
- Conclusion => List some limitations of the proposed scheme as compared to the literature, not necessary to the standard. Finally, list some open research challenge to be leveraged in further studies
Minor Comments
L1. I would suggest adding the abbreviated form on “Internet of Things (IoT)”
L6. Did you mean “end-device”?
L12. “E-Health systems” should be mentioned in the Abstract text. Since the manuscript seems not to refer to this keyword, I suggest it be removed from the list.
“Internet-of-Things” => Did you mean “Internet of Things”?
I suggest adding the % of the growth between the years in Fig.1. Save space in the upper part of the graph. No need to display the figure above 80 of the f(x) axis.
Fig. 2. => “Mission critical outdoor use case High Power”. I think this text should be reformulated. Maybe, there are more than one element in the string
L23. “and many nodes.” => did you mean “and high density of nodes”?
L23-24. “In addition, the LoRa Alliance [5] and Sinha et al. [6] the Low-PowerWide-Area Network (LPWAN) industry is up-and-coming.” => Sentence to be reformulated
L27-28. “LoRa [9] is a well-developed LPWAN technology among these LPWAN technologies “. => Delete the first call of LPWAN Omit to avoid redundancy in the sentence.
L72-74. Should be reformulated or removed since doesn´t seem to be contextualized to this part of the section
L100. “…a low-power” should be omitted since it appears afterwards in a better position for the sentence
L102. “Diagram” => did you mean “Figure”
L114. “receiving windows” => Do you mean "Receive Windows"?
L116. “The” Receive Windows...
L126. “accept” => I would rather suggest a lowercase for “A”
L133-134. => “..identification and assigned by ..”=> “…identification that is assigned by…
Fig.4 => I suggest it be displayed within or after 2.2.2 section
L168. => “is a message integrity code and …” => To be omitted since MIC has already been defined above
Table 1 => articles (a, an) can be omitted at the beginning of the sentences for the Meanings
L177-180. => To remove the bullet points
L178. “…assigns every…” => To be reformulated
L180. “publishes symmetric encryption and decryption, and a one-way hash functions.” => To be reformulated. Sentence incomplete. at least, the beginning seems to be lacking something.
L196. “end-dvice.” => letter “e” missing
I cannot find the sentences in the manuscript that introduced Figures 6, 7, 8, and 9
L223. “w provide” => letter “e” missing
L259 and L291 => What is the meaning of the box? Is it relevant to the manuscript? If yes, keep it, otherwise, I suggest it be removed
L378. “LoRawan” => LoRaWAN
Author Response
Answers to Reviewer 3
In this paper, the authors suggest an authentication approach and mechanism for the end-device join session to the LoRaWAN network.
The proposed scheme is claimed to be more efficient than the one on the LoRa Standard in terms of join latency. In addition, the authors assessed the authentication overhead and compare it to the standard approach in scenarios of 50, 100 and 1,000 end-devices. These figures represent the typical densities in LoRaWAN networks and the maximum number of end-devices in such networks.
The proposed authentication system was assessed formally and is secure against the server and end-device impersonation.
Comment R3.1: List some limitations of the proposed scheme as compared to the literature, not necessary to the standard.
Response to R3.1: We are thankful for your valuable suggestion. We mentioned some limitations of the proposed protocol in the revised manuscript suitably.
- For an end-device, each network server shares a secret key with the end-device. We limit the proposed scheme with an assumption that such key cannot be stolen or modified at any means.
- The proposed scheme does not discuss any situation where a physical attack could be possible. If so, how to achieve a device revocation will be our future research.
Comment R3.2: Finally, list some open research challenge to be leveraged in further studies
Response to R3.2: We are thankful for your valuable suggestion. We mentioned some interesting open challenges in the revised manuscript.
Comment R3.3: L379. Is 1000 the limit for a network per gateway?
Response to R3.3: We are thankful for the comments. The number of devices is 1000, which is not a network limitation per gateway. However, we studied earlier works and found most of the results considered 1000 per gateway. To make an ideal comparison, therefore, we considered the same number.
Comment R3.4: Minor Comments
L1. I would suggest adding the abbreviated form on “Internet of Things (IoT)”
Response: We have added it.
L6. Did you mean “end-device”?
Response: Thank you for the comments. We have corrected it.
L12. “E-Health systems” should be mentioned in the Abstract text. Since the manuscript seems not to refer to this keyword, I suggest it be removed from the list.
Response: We have removed it.
“Internet-of-Things” => Did you mean “Internet of Things”?
Response: We have corrected it.
I suggest adding the % of the growth between the years in Fig.1. Save space in the upper part of the graph. No need to display the figure above 80 of the f(x) axis.
Response: We have added % of the growth compared to its preceding year. Besides, we bound the f(x) axis to 80 as suggested.
Fig. 2. => “Mission critical outdoor use case High Power”. I think this text should be reformulated. Maybe, there are more than one element in the string
Response: We have updated Fig. 2 according to the comment.
L23. “and many nodes.” => did you mean “and high density of nodes”?
Response: We have corrected it.
L23-24. “In addition, the LoRa Alliance [5] and Sinha et al. [6] the Low-PowerWide-Area Network (LPWAN) industry is up-and-coming.” => Sentence to be reformulated
Response: We have corrected it to “Furthermore, according to the LoRa Alliance [5] and Sinha et al. [6], the Low-Power Wide-Area Network (LPWAN) business is on the rise in the IoT market.”
L27-28. “LoRa [9] is a well-developed LPWAN technology among these LPWAN technologies “. => Delete the first call of LPWAN Omit to avoid redundancy in the sentence.
Response: We have deleted first call of LPWAN.
L72-74. Should be reformulated or removed since doesn´t seem to be contextualized to this part of the section
Response: We have removed it from that part of the section.
L100. “…a low-power” should be omitted since it appears afterwards in a better position for the sentence
Response: We have removed it.
L102. “Diagram” => did you mean “Figure”
Response: We have corrected it.
L114. “receiving windows” => Do you mean "Receive Windows"?
Response: We have corrected it as “Receive Windows”.
L116. “The” Receive Windows...
Response: We have corrected it.
L126. “accept” => I would rather suggest a lowercase for “A”
Response: We have corrected it as “accept”.
L133-134. => “..identification and assigned by ..”=> “…identification that is assigned by…
Response: We have corrected it.
Fig. 4 => I suggest it be displayed within or after 2.2.2 section
Response: We have updated the position of Fig. 4 as suggested.
L168. => “is a message integrity code and …” => To be omitted since MIC has already been defined above
Response: We have removed it.
Table 1 => articles (a, an) can be omitted at the beginning of the sentences for the Meanings
Response: We have updated Table 1 based on the comment.
L177-180. => To remove the bullet points
Response: We have updated L177-180 based on the comment.
L178. “…assigns every…” => To be reformulated
Response: We have corrected it.
L 180. “publishes symmetric encryption and decryption, and a one-way hash functions.” => To be reformulated. Sentence incomplete. at least, the beginning seems to be lacking something.
Response: We have updated L180 based on the comment.
L196. “end-dvice.” => letter “e” missing
Response: We have corrected it.
I cannot find the sentences in the manuscript that introduced Figures 6, 7, 8, and 9
Response: We have updated text, and Figures 6, 7, 8, and 9 can been seen on L236, L309, L343, and L376 respectively.
L223. “w provide” => letter “e” missing
Response: We have corrected it.
L259 and L291 => What is the meaning of the box? Is it relevant to the manuscript? If yes, keep it, otherwise, I suggest it be removed
Response: The box is a symbol that represents that the respective theorem is proved.
- “LoRawan” => LoRaWAN
Response: We have corrected it.
Response to R3.4: We are thankful to the reviewer for the remarkable comment. We incorporated all comments in the manuscript, and the individual responses can be seen above.
Author Response File: Author Response.pdf
Round 2
Reviewer 2 Report
Thanks for adressing my comments. From my side it is fine.
