No. There is no concept of a “default key” or a “default password” in LoRaWAN. All
end-devices are equipped with unique keys when they leave the manufacturer. As a
consequence, any compromise of a key from one end-device will not have an impact on
other end-devices.
Where are the LoRaWAN™ security mechanisms specied?
What kind of identiers are used in LoRaWAN?
Can I randomly assign any identier to
my device or my network?
Are there any differences between the ABP (Activation-
by-Personalization) and OTAA (Over-the-Air-Activation)
methods in terms of security?
Are all end-devices equipped with the same “default”
cryptographic key when leaving the manufacturer?
How do the LoRa Alliance specications ensure
secure operation of LoRaWAN networks?
01.
04.
05.
06.
02.
03.
All security mechanisms are specied in the LoRa Alliance™ specications that
can be downloaded by the public from https://www.lora-alliance.org/Contact/
RequestSpecicationForm.aspx
Currently, LoRaWAN Release 1.0 and 1.0.2 are available for download. Release 1.1 is
under construction. This FAQ is based on the LoRaWAN 1.0.x specications.
Each end-device is identied by a 64-bit globally unique Extended Unique
Identier (EUI-64) that is assigned either by the manufacturer or the owner of the end-
device. Allocation of EUI-64 identiers require the assignor to have an Organizationally
Unique Identier (OUI) from the IEEE Registration Authority.
Each Join Server, which is used for authenticating the end-devices, is also identied by
a 64-bit globally unique identier (EUI-64) that is assigned by either the owner or the
operator of that server.
Open LoRaWAN networks and private LoRaWAN networks that are collaborating
(roaming) with the open networks are identied by a 24-bit globally unique identier
assigned by the LoRa Alliance.
When an end-device successfully joins a network, it gets a 32-bit ephemeral device
address assigned by the serving network.
LoRaWAN uses static root keys and dynamically-generated session keys.
Root keys are only provisioned in OTAA end-devices. They are used to derive session
keys when the OTAA end-device executes a Join Procedure with the network. An
OTAA end-device, when installed in the eld, will be able to connect to any network
that has an interface to the key server (which is called a Join Server in Release 1.1)
to which the end-device is associated. Session keys are used by the end-devices to
protect the over-the-air trafc.
ABP end-devices are not provisioned with the root keys. Instead, they are provisioned
with a set of session keys for a pre-selected network. The session keys remain the
same throughout the lifetime of an ABP end-device.
LoRaWAN supports origin authentication, integrity and replay protection of the complete
Media Access Control (MAC) frame. It also enables end-to-end encryption of the
application payload between the end-device and its counter-part on the network side
(which is called the Application Server in Release 1.1). LoRaWAN supports a mode of
operation that allows encryption of the MAC commands.
All of these procedures rely on the Advanced Encryption Standard (AES) and use 128-bit
cryptographic keys and algorithms.
No. Please see question #4 about the assignment authority for each identier. Not
following these guidelines would cause identier collision and unpredictable behavior in
your network deployment (similar to what happens when using the same Ethernet MAC
address on multiple devices attached to the same LAN).
The ability to rekey session keys makes OTAA devices more suitable for applications
requiring a higher level of security.
FREQUENTLY
ASKED QUESTIONS
LoRaWAN™ SECURITY