from a security point of view I found something in relation to replay attacks against LoRaWAN and it seems like storing the latest n JoinRequest messages is needed to prevent an replay attack against the network server - in our case the TTN.
Does anyone know how many JoinRequest messages are stored by TTN until somebody could replay an old JoinRequest in order to establish the same session details?
Seems like this information is hidden somewhere inside TTN and not available to public?
If you found a security threat, we kindly ask you, as a security researcher, to:
Contact us to report any security vulnerabilities found in any of our community websites, our community network deployments or our open source repositories.
Contact us privately through the means listed on this page.
Support us in solving the issue (if you have the technical skills to do so).
Refrain from requesting compensation for reporting vulnerabilities.
Wait for 14 days after we released and deployed a fix before announcing or publishing the details of the vulnerability.
Provide us with links to your announcements and/or publications regarding the vulnerability.
Actually I’m refering to the paper by Gildas Avoine -> https://www.semanticscholar.org/paper/Rescuing-LoRaWAN-1.0-Avoine/e21cb378a92b30f8ebb4252ebdd2e2f378f0507d chapter “3.1.2 Targeting the NS”
-> “According to the specification, the NS must keeptrack of “a certain number” of received DevNonce values in order to prevent replay attacks, withoutclarifying if this means all values or a few of them.”
But how big is the number of DevNonces (and therefore JoinRequests) in case of TTN? Or are there any other countermeasures in place?
yes I understand… there are several papers on theoretical LoRaWAN attack vectors.
let’s say there haven’t been a succesfull LoRaWAN replay ‘attack’ on TTN as far as I know. at least not publiced
