- [Man] LoRA or LoRA WAN networks operate
in the 868 megahertz and 900 megahertz ISM bands.
The data rates can be from 0.3 kilobits per second
to 50 kilobits per second
over several kilometers.
And that's one of the main differences
between LoRA and the all the other technologies
that we cover related to IoT communications.
Now LoRA supports several device types
including low power sensors that collect data in the field.
LoRA devices communicate with a LoRA gateway
and that gateway sends data to a network server.
And on to application, you know
servers accessible by the administrators of LoRA devices.
Let's go over the LoRA one security model.
LoRA specifies two types of symmetric session keys.
These are unique to each LoRA device.
The Network Session Key
for networks layer messaging manages integrity
from you know, basically the LoRA device
to the LoRA network server.
And also the App Session Key is, you know
the other key that is actually used
for application layer end to end encryption
from the LoRA device to the application server.
Now, there are two ways that devices
can join the network, right?
The first is over the air activation or OTAA
and the basically the LoRA device and the network server
our first provision with 128 bit AppKey.
And then when the LoRA device is first powered on,
it will send a joint request to the LoRA network server.
The AppKey is used to create a Message Integrity Code
or a MIC along with information including
the device ID and the device nonce.
The server checks the MIC with the AppKey.
And then after validation,
the network server generates two new 128 bit key
you know, device keys, the App Session Key
or the App S Key and the Network Session Key
which is also called the NWKS key, right?
Now, the keys are sent back to the LoRA device
using the AppKey as the encryption key itself, right?
Then the LoRA device decrypt and install the session keys.
The other method is the activation
by personalization or ABP.
Basically the LoRA device is provisioned with session keys
you know, the Network Session Key and the App Session Key
and this can be done at manufacturing time.
Now this LoRA devices can be in communicating
with the LoRA network server using those keys.
Now, one to highlight is that man in the middle of attacks
are pretty unlikely because of the uniqueness
of these session keys.
This is somewhat stronger than the other IT protocols
that we cover earlier in the course.
There are other potential threats, although for example
the ABP key provisioning.
So the activation by personalization creates session keys
for the LoRA device possibly at manufacturing, right?
So these session keys have to be injected into the device
and securely transported to the LoRA network server.
So again, there's a of course the potential
of supply chain attacks in that case, right?
Now there's hardware security modules or HSMs
at the manufacturing site that can actually
be implemented to be the best way to do this.
You know, these key management so that
the keys are not exposed during the device programming.
So the LoRA device programming.
Now, another thing is that
during the over the air activation or OTAA,
that process actually uses a secure methodology
for generating session keys.
However, the app key must be provisioning a secure manner
and securely transported to the network server.
And this could be done over HTTPS
in a secure web client server model.
However, if the implementer or the vendor does not configure
or does not enable HTTPS or TLS by default,
there will definitely be an opportunity
for you as an attacker to actually eavesdrop.
But that's of course, very unlikely.
You know, there's a lot of guidance by the LoRA community
that actually highlights this
you know, in many different type of documentation, right?
So, but again, the possibility is still there.
Now, LoRA device key storage is another consideration
that you know, may also have to take care, you know,
as an attacker you may actually have access
to the device keys, the AppKey, the Networks Session Key
and the App Session Key, and you can easily spoof
and node if you actually have those in your possession.
So therefore that's why these keys definitely
should be stored securely not only within an environment
but within those devices themselves.
Right? So encryption at rest is actually one
of the main things that, you know, implementers
should pay attention to.
Now, well known sided channel attacks
can also be used to recover these keys
from memory that is actually not accessible
via software means, right?
A mitigation for that is actually smart car chips.
And these are secure elements that have been designed
for side channel protections.
Now, another consideration is the Client-Side Key Storage.
Depending on the application server architecture,
the client could be responsible for the secure key storage
of all those keys zero.
So the App key, the Network Section Key
and the App Session Key.
So to mitigate the threat of, you know,
this type of exposure, all device keys
are encrypted under a master key.
So they're not exposed whenever in use, right?
Clients and implementers can also employ a USB smart key
to protect key material in a physical device, right?
Now another consideration is also
the LoRA network server key storage.
And again, it's actually the network server
is used to generate the device keys
for all the LoRA devices.
So if it's actually compromised, of course
you actually have the keys to the kingdom.
In that case, all device keys should be encrypted
under the master keys to actually mitigate threats
of exposure.
So in summary, the main security risk
with LoRA is the key life cycle management.
This includes the session key, the generation, you know
that session key, the storage and the transport.