Volgens bepaalde documenten van het LoRa Consortium zou LoRaWAN gebruik maken van het AES 128-algoritme voor het versleutelen van berichten. Maar volgens de Franse veiligheidsspecialist Renaud Lifchitz wordt het AES 128-algoritme in werkelijkheid alleen gebruikt om een reeks van sleutels te genereren, een zogenaamde “keystream”, die gewoon wordt ge-XOR-d met de data. Het resultaat is een niet-optimale versleuteling die is te ontcijferen door iemand die dat graag wil.

Door het XOR-en van de data met de sleutel ontstaan versleutelde berichten met dezelfde lengte als de sleutel, dat is al een sterke aanwijzing voor hackers. Bovendien wordt de keystream opnieuw gestart bij het begin van een sessie en kan deze hetzelfde zijn als een eerder gebruikte keystream. Dat maakt het mogelijk om oude berichten opnieuw te versturen. Door twee berichten die met dezelfde keystream zijn versleuteld met elkaar te XOR-en worden beide berichten gedeeltelijk gedecodeerd. En als de inhoud van een bericht bekend is, is het mogelijk de keystream af te leiden uit het gecodeerde bericht, wat het ontcijferen van toekomstige berichten mogelijk maakt.

Er ligt ook een zwakheid in het proces van identificatie en opbouwen van een verbinding. Elke gateway stuurt zijn ID periodiek naar de server. Als die ID bekend is, en die informatie is niet zo moeilijk te verkrijgen, dan kan de gateway worden “overruled” door een aanvaller die gewoon dezelfde ID stuurt in een hoger tempo dan de echte gateway.

Maar de belangrijkste zwakheid blijft toch wel de hardware die communiceert via LoRa. Dit zijn vaak eenvoudige systemen met een onbeschermd geheugen, debug-poorten en naïeve AES-implementaties die gemakkelijk kunnen worden aangevallen. Zoals bekend is een systeem net zo sterk als de zwakste schakel.

LoRa’s concurrent Sigfox doet het trouwens niet veel beter