Topics gestart door Lennart Nordin

16 Topics

Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

LoRaWAN Security: Encryption and Authentication

End-to-end encryption All LoRaWAN devices are forced to encrypt their payload and header with the Advanced Encryption Standard (AES), using keys of 128 bits (or 32 hexadecimal characters). The LoRaWAN protocol offers two layers of security: On the network layer, the integrity of a message is enforced by the Message Integrity Code (MIC). On the application layer the payload is encrypted using the AppSKey. This means it is possible to have end-to-end encryption of the LoRa data. For LoRaWAN the used network keys are in the KPN domain and the application keys are in the customer domain and must comply to usage policies to prevent easy to guess variables. In the case of Over The Air Activation (OTAA) the used Network Session Key (NwkSKey) and Application Session Key (AppSKey) are managed from the KPN domain (Join service) and can be periodically refreshed. The below figure shows the domain of the NwkSKey and the AppSKey. KPN Security mechanisms KPN depends not only on th

13
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

LoRaWAN Device Classes: A, B and C

The LoRaWAN protocol is capable of transferring sensor data or changing the behavior of an actuator. LoRaWAN can be used for both uplink and downlink messaging and within LoRaWAN there are three traffic categories defined, namely Class A, Class B and Class C. Class A (default) Class A is the default device class, used for battery powered sensors or actuators. Each uplink message is followe by two receive slots for downlink messages. Downlink transmissions are queued in network until next uplink creates two receive slots. Between uplink messages and downlink receive windows (RX1 and RX2), the device is in sleep mode and the battery is preserved. Note that the network cannot send a downlink until the device wakes up (triggered by an event on the device like a timer or a sensor threshold). Class B (Beacon) Class B communication is based on slotted communication that is synchronized with a network beacon. Currently this feature is not yet enabled in the KPN LoRa network. Cla

9
Gustavo Woltmann
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

The Replay Attack Prevention mechanism enhances the network security

Bij de afgelopen update van ThingPark, versie 4.3, is er een Replay Attack Prevention-mechanisme geïntroduceerd in het netwerk. Dat betekent dat het netwerk de frame counter (FCntUp) gebruikt om te beoordelen of een binnenkomend bericht een valide bericht is. Als er een bericht binnenkomt met dezelfde counter als het vorige bericht, dan zal het bericht genegeerd worden. Deze nieuwe functie werkt zowel voor ABP- als voor OTAA-devices. Als gevolg van dit nieuwe mechanisme is het niet meer mogelijk om devices na elk bericht uit te schakelen zonder de counter-waarde op te slaan. Omdat bij het uitschakelen van het device de counter-waarde gereset wordt, stuurt het device alleen maar berichten met FCntUp=1. Alle binnenkomende berichten worden dan genegeerd door het netwerk, waardoor het lijkt alsof de berichten van het device niet meer doorkomen in de Applicatie Server. Op de alarmenpagina in ThingPark zal je dan ook waarschuwingen zien dat een frame replay is geblokkeerd. Het constant re

8
T
KPN Moderator
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

Certification and requirements of LoRaWAN devices

Device certificationTo ensure that KPN’s customers will experience the same quality of the KPN LoRa network as any other high quality KPN mobile network, all LoRa devices that are connected to the KPN LoRa network must be certified. Certification of the LoRa devices can be performed by several official test houses that are working with the LoRaWAN Certification Program. An actual overview of certified devices can be found on the website of the LoRa Alliance.In order to enable development, KPN allows small volumes of uncertified devices on the network. This is only allowed in development projects that have a goal of certification in the long term. The LoRa Developer portal is specifically intended to help in this type of development.When devices or modules are used that are certified themselves, no extra certification is needed as long as no changes are made to the devices of modules that could impact certification. However, in case the implementation of the LoRaWAN protocol on certifie

5
ryan991205
4 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

There are online LoRa tools and reference code available to make your life easier

There are several online tools and references available to help you along with your LoRa service. In this post two websites providing tools and reference code are provided: www.LoRatools.nl . This website provides four tools, namely: Key generator. LoRa customers that have access to a ThingPark account have to provide an LRC-AS key, which is used for the encryption and decryption of the data. The Shannon Entropy of the key should be at least 3.7. This generator provides 16 Byte keys which fulfill this Entropy requirement. On top of that, keys with a different amount of bytes can be generated if desired. Note that the safe storage of these keys is the responsibility of the customer and that when multiple devices are commissioned, one should use unique encryption keys for each device. HEX helper. This tool can be used to convert the style of your HEX string. ThingPark import helper. LoRa users with a ThingPark account have the possibility to provision devices usin

4
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

LoRaWAN best practices

An IoT implementation can be quite challenging especially when a developer is not familiar with all areas. When adapting new technology people ask for best practices to make sure they are not reinventing the wheel. The points below give a first overview and guidelines that can be quite helpful for new solution providers and device makers. ADR and Join Before joining the network, it is advised to set the device spreading factor to SF12 and enable ADR. This should result in sending out the join message on SF12 to have the greatest possible chance that a network join will be successful. ADR and maximum payload Since the maximum payload length is related to the Spreading Factor, the application must know in which SF a message will be sent to determine the maximum payload length. To be sure data will fit all SFs the maximum payload length of SF12 which is 51 bytes can be used. In order to maximize the efficiency of communications in all situations (whatever the radio condition

2
T
KPN Moderator
4 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

Uplink and Downlink messages and the Duty Cycle

Uplink and Downlink messages LoRaWAN supports both uplink as downlink messaging; messages from end-device to the network are called uplink and network to end-device messages are called downlink. The most common way to use LoRaWAN is to use the uplink so a sensor can report any value to the Application Server. Under certain conditions it might be useful to use a downlink message to provide the sensor with an acknowledgment to make clear that the message has arrived in the network and will be forwarded to the Application Server. Downlink messages can also be used to control settings of the sensor, for instance to adjust its update frequency or any other settings on the appliance. Another application of downlink messages could be to control an actuator like a valve or a lock. If you are sending downlinks (from the Application Server to the end-device) these are in theory unconfirmed messages. Although there is a message log in the Wireless Logger the information reported gives no indica

0
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

Application Server SSl certificates and authentication tokens

Application Server SSL certificates Any customer Application Server needs to have a valid SSL certificate to create a secure HTTPS connection. The responsibility of retrieving the SSL certificate and keeping track of the validity is with the customer. The KPN LoRa server accepts SSL certificates from most major SSL certificate authorities. If your Application Server does not have an SSL certificate, you can shop online for one. A paid version can be obtained at https://www.thesslstore.nl/ or https://www.sslcertificaten.nl/ for instance or you can use the limited free version of https://letsencrypt.org/. Which one you use is up to you. When there is no certificate or if it is not valid, KPN will not forward the data. Tooling to test the validity of your SSL certificate can be found online, for example here. Application Server authentication tokens Within the application data stream an authentication token is used to validate authenticity of the data. This authentication token

0
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

Setting up your Application Server

Data from a LoRa End-Device can be forwarded to an Application Server of your choice. The Application Server can be any public URL on the internet and can be your own server or somewhere in the cloud. The connection between the KPN LoRa network and the customer Application Server uses Internet connectivity and the application connection is established using HTTPS. By using HTTPS, the confidentiality of the interface is managed and certificates ensure the identity of both the receiver and server side. Application Server authentication The connection between the KPN Network Server and the customer Application Server uses two separate authentications (one for the Application Server and one for the Network Server), which together lead to mutual authentication: The customer Application Server needs to have a valid SSL certificate. Within the application data stream an authentication token is used to validate authenticity of the data. These two levels of security are used b

0
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

LoRaWAN Channels

Currently KPN’s network supports the 8 channels shown below. When configuring devices, customers must make sure they support at least the first 3 LoRaWAN default frequencies and enable ADR, because the other channels will be added dynamically and could vary for each region. In the future, 16 channels will be supported, however, this functionality is not expected shortly.

0
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

Welcome to the KPN LoRa forum. An overview

Welcome to the KPN LoRa forum! If you are new to (KPN) LoRa then this is the place to start. For the more experienced users this post can be used as an overview. Introduction The first thing to look at is the General overview of LoRa and LoRaWAN. This explains the basic concept of the LoRa network and once you are acquainted with it, a good next step is to look into the KPN implementation of LoRaWAN. As you might already have noticed, this technology comprises a lot of terminology, for which one can refer to the The LoRa Dictionary & Definitions post. It should be noted that this forum serves both users of the free LoRa developer portal and contracted users of the ThingPark platform. This means that certain specific aspects or topics on this forum might not completely apply to your situation. On top of that, the same goes for customers that are contracted via a reseller (SIMPoint). The response on questions posted on this forum is based on best effort. For KPN's contracted cu

0
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

The KPN implementation of LoRaWAN

KPN’s Low Power Long Range (LoRa) network service is based on a relatively new LPWAN protocol for IoT and supplements existing 2G, 3G and 4G networks. The network eliminates significant barriers such as cost and energy consumption so that numerous (battery powered) devices can be connected. KPN has equipped hundreds of existing mobile transmission towers across the Netherlands with a LoRaWAN gateway and antenna, allowing millions of devices to be connected. Future functionality will also include roaming of end-devices on foreign partner networks. The figure below provides an overview of an IoT solution connecting sensors to an Application Server. In the figure, the following components can be distinguished: Sensor Communication Device KPN Network (including software platform) Application Server Application The service includes the use of a software functionality, the KPN LoRa platform, which is powered by the Actility Thingpark platform. The KPN LoRa platfor

0
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

What is LoRa and LoRaWAN?

The radio and modulation part of the LPWAN technology is specified and patented by the company Semtech. The LoRa Alliance is in charge of standardizing the LoRaWAN part of the stack. The below figure gives a graphical representation of the complete stack. LoRa LoRa is an abbreviation of 'Long Range Low Power' and enables sending small amounts of information between objects with very low power. LoRa receivers are very sensitive due to spread spectrum, allowing the sender to send with very low power even when noise is high and distance are far. See for instance www.link-labs.com/what-is-lora/ for a more in depth discussion of LoRa spread spectrum Modulation. LoRaWAN LoRa Wide-Area-Network (LoRaWAN) uses LoRa modulation to build a network of a few gateways (cell-towers) to communicate with many devices. Basically it is a set of rules on how to communicate and what protocols to use. The full specifications of the LoRaWAN protocol can be requested at the LoRa Alliance for free.

0
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

Spreading Factor (SF), Time on Air and (Adaptive) Data Rate

Data Rate Communication between end-devices and gateways is spread out over different frequency channels and data rates. The selection of the data rate is a trade-off between communication range and message duration. Within the selected channel the LoRa protocol, which is a chirp spread spectrum modulation technique, determines how many bits are required to code the data (coding rate) which results in a maximum data rate. Spreading Factor The basic principle of spread spectrum is that each bit of information is encoded as multiple chirps. Within the given bandwidth the relationship between the bit and chirp rate for LoRa modulation may differ between spreading factor (SF) 7 to 12. The end-device may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected: The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust to interferen

0
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

LoRa device identifiers and addresses

This topic provides some background information regarding the device addresses and identifiers that are used in the LoRa network. The identifiers are split up into two sections, namely the identifiers used in the OTAA Join process and the identifiers used during a data session. OTAA device provisioning DevEUI. Each device joining the KPN LoRaWAN network needs to have a unique identifier. This identifier is called the DevEUI and it must be a unique IEEE MAC address. A device manufacturer must acquire an address block with IEEE or when the customer requires a small "sub block" this can be requested from KPN. There are 3 available ranges from IEEE, namely MAC-L, MAC-M and MAC-S. For of the shelf LoRa devices the manufacturer should already have a range of addresses and then each device should be delivered with its pre-defined DevEUI AppEUI. The 64-bit AppEUI which is used as an identifier for an application instance is also a unique identifier. AppKey. The 128-bit AppKe

0
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

Over the air activation (OTAA) of devices

When OTAA is used for the activation of devices, the DevEUI, AppEUI and AppKey are needed to register the device on the KPN LoRa network. The NwkSKey and AppSKey are derived when joining the network. OTAA Join procedure During the OTAA Join the network forwards the join request message to the Application Server identified by the AppEUI. This Application Server is supposed to have been provisioned with the end-device's AppKey. Based on the AppKey and the content of the Join request message sent by the end-device, the Network: Generates a NwkSKey and AppSKey and sends the NwkSKey information to the KPN Core Network. Forms a Join response payload that will allow the end-device to compute a NwkSKey and AppSKey. OTAA re-join The advice for the frequency of periodically rejoining (and thus renewing the NwkSKey and the AppSKey) depends on the number of messages sent by the end-device and the level of security required. A device should re-join: Every time it has los

0
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden

Badges

Toon alle badges
Forumvoorwaarden