I’m wanting to use some Cryptography functions to indentify my devices. ( using microchip ATEC608A on the device ). I’m looking at two different approaches;
(a) Dive into the lorasever.io code and see if i can figure out what i’d need to do to modify / extend it to support the secure connectivity. The downside of this, is that i dont’ know go.
(b) Write a secure join server and then use it along side Loraserver. ( using something that i do know ).
I need to do some more work to udnerstand what needs to be passed between the NS and the JS. Does anyone know where that is defined?
Please note that a secure element does not change the way how OTAA works. It improves the security by putting the root-key(s) in a secure-element. The OTAA handshake is still the same.
If you are referring to using an external join-server, this is already (partly) supported. Please see the join-server configuration in the loraserver.toml file.
# Join-server settings.
[join_server]
# Resolve JoinEUI (experimental).
# Default join-server settings.
#
# When set to true, LoRa Server will use the JoinEUI to resolve the join-server
# for the given JoinEUI. LoRa Server will fallback on the default join-server
# when resolving the JoinEUI fails.
resolve_join_eui=false
# Resolve domain suffix.
#
# This configures the domain suffix used for resolving the join-server.
resolve_domain_suffix=".joineuis.lora-alliance.org"
# Join-server certificates.
#
# Example:
# [[join_server.certificates]]
# # JoinEUI.
# #
# # The JoinEUI of the joinserver to to use the certificates for.
# join_eui="0102030405060708"
# # CA certificate (optional).
# #
# # Set this to validate the join-server server certificate (e.g. when the
# # certificate was self-signed).
# ca_cert="/path/to/ca.pem"
# # TLS client-certificate (optional).
# #
# # Set this to enable client-certificate authentication with the join-server.
# tls_cert="/path/to/tls_cert.pem"
# # TLS client-certificate key (optional).
# #
# # Set this to enable client-certificate authentication with the join-server.
# tls_key="/path/to/tls_key.pem"
# Default join-server settings.
#
# This join-server will be used when resolving the JoinEUI is set to false
# or as a fallback when resolving the JoinEUI fails.
[join_server.default]
# hostname:port of the default join-server
#
# This API is provided by LoRa App Server.
server="http://localhost:8003"
# ca certificate used by the default join-server client (optional)
ca_cert=""
# tls certificate used by the default join-server client (optional)
tls_cert=""
# tls key used by the default join-server client (optional)
tls_key=""
# Join-server KEK set.
#
# These KEKs (Key Encryption Keys) are used to decrypt the network related
# session-keys received from the join-server on a (re)join-accept.
# Please refer to the LoRaWAN Backend Interface specification
# 'Key Transport Security' section for more information.
#
# Example (the [[join_server.kek.set]] can be repeated):
# [[join_server.kek.set]]
# # KEK label.
# label="000000"
# # Key Encryption Key.
# kek="01020304050607080102030405060708"
1 Like
If I understand correctly, loraserver.io implements the ‘join’ service ‘internally’ (as part of the network server) unless you specify an ‘external’ one? Is that correct?
Yes, you have to enable to use an external one (resolve_join_eui=true). As marked, this is still experimental as the NS <> JS security isn’t fully specified (yet) by the LoRa Alliance.
By default LoRa Server will use LoRa App Server as the Join-Server 
(also when the resolve_join_eui would fail).
1 Like
Thanks, that makes things a bit clearer for me.
I need to go and read the specifications now, to understand what the transactions are (NS <–> JS ).
I’m contemplating attempting to create a JS as a Python based Lambda in AWS…
1 Like
@brocaar @mrpackethead
if we configure below configuration in loraserever
resolve_join_eui=true
join_eui="0102030405060708"
loraserver can join only above join_eui devices?
If loraserver will receive different join_eui so it will discard that request?
how can i configure resolve_domain_suffix (can you please give small example)
resolve_domain_suffix=".joineuis.lora-alliance.org"
Thanks
@mrpackethead, just wondering if you were you able to implement this?
Hi @brocaar
You have mentioned Secure element join doesn’t affect how OTAA works right.
Query:
But to add the device to the chirpstack server we need to provide appkey while creating the device.
- Can you give an example .toml file for configuring “The Things Join Server” to the Chirpstack Network server?
- How to add the device without providing Appkey?
Hi @brocaar
I am trying to use an external Join Server to handle the Join Requests of some devices. So, I created an OTAA device without setting the AppKey.
I have tried to configure the JS settings in the chirpstack-network-server.toml as below to use an external Join Server to handle the join requests.
[join_server]
resolve_join_eui=true
resolve_domain_suffix=".joineuis.lora-alliance.org"
[join_server.default]
server="http://localhost:8003"
The device is configured to use the JoinEUI of the external Join Server. However, when the device sends a Join Reqest, I am seeing the below error. Could you please help me how I can proceed further?
Apr 03 10:22:02 ip-172-31-33-119 chirpstack-network-server[11485]: time="2021-04-03T10:22:02Z" level=info msg="uplink: frame(s) collected" ctx_id=7dd67686-6234-403d-8c47-3035971664a5 mtype=JoinRequest uplink_ids="[047613f3-e871-4c98-ba56-2babd95e86e2]"
Apr 03 10:22:03 ip-172-31-33-119 chirpstack-network-server[11485]: time="2021-04-03T10:22:03Z" level=info msg="finished client unary call" ctx_id=7dd67686-6234-403d-8c47-3035971664a5 grpc.code=OK grpc.ctx_id=dafc123f-16d1-4763-b38b-55655c065050 grpc.duration=3.197384ms grpc.method=HandleError grpc.service=as.ApplicationServerService span.kind=client system=grpc
Apr 03 10:22:03 ip-172-31-33-119 chirpstack-network-server[11485]: time="2021-04-03T10:22:03Z" level=error msg="uplink: processing uplink frame error" ctx_id=7dd67686-6234-403d-8c47-3035971664a5 error="join-request to join-server error: http post error: Post \"https://0.0.0.0.0.0.0.d.e.7.5.d.3.b.0.7.joineuis.lora-alliance.org\": x509: certificate signed by unknown authority"
Is your external join-server reachable through https://0.0.0.0.0.0.0.d.e.7.5.d.3.b.0.7.joineuis.lora-alliance.org??
Hii
what is Join server ? When its exactly use ?
is there JoinEUI is needed for this join server to identify ? but some case we put this joinEUI as 00000000000…
exactly when its come into picture and is this software or hardware ?
provide some detail easy explanation of this join server ?
i am currently trying to onboard the end device using QR code with one mobile application ?
provide some suggations to do this project ?
Thank you…
Frankly this is a pretty easy google but I’ll help out.
In typical LoRaWAN architecture their are three software components server side. The network server (NS), the join server (JS), and the application server (AS). The JS is what generates and stores the keys that are used to encrypt and decrypt the LoRaWAN packets. When the NS receives a join-request from one of your devices, it would tell the JS to generate keys for it, a network session key that gets passed to the NS, and an application session key that gets passed to the AS. The application session key is the key that actually decrypts the sensor info from the LoRaWAN packet, the network session key I believe just decrypts some meta data used to determine whether the packet is for your network. The reason for this separation is typically just for large / public networks. For example if you were using TTN, you wouldn’t want them to be able to decrypt all of your sensor data just because they own the network server, so you can specify your own join-server and application server such that they do not have knowledge of your keys, and cannot see your data.
In default Chirpstack on the other hand, all of this is irrelevant. As it acts as all three parts NS/JS/AS innately. That is why you can input 0s for the joinEUI (which typically is an identifier for the JS) as Chirpstack is it’s own JS so the value can be anything and it will still join. Chirpstack generates its own keys and stores them in its postgresql/redis databases)
Chirpstack does have the option for an external join server though, which is what the rest of this discussion is about, but because you own your own server, the only reason you would want to do this is if you had clients who cared heavily about security and were technical enough to handle their own application server.
Just have the QR code contain the devEUI and appKEY of the device, and when the app detects it have it trigger a script to add the device to Chirpstack using the gRPC API.
1 Like
Thank you for your explanation.
I have some more doubts regarding this AppKey and JoinEUI
Who will provide these two keys ?
Exactly where we can store these keys for usage ?
Is these keys are same for all end nodes or different ? if same they are collide with some other nodes ?
Now i am currently working on the automate onboard process of end device using QR code ? According lora alliance in QR standard , there is no AppKey in that . who will provide this key and how it will add to Network server ?
In join server and end device have stores the AppKey , How it will store and who will provide ?
Most devices come with the appKey and devEUI. JoinEUI is useless for Chirpstack. Chirpstack stores the keys. devEUI is unique, appKey not necessarily.
I suggest you do some more research yourself. It seems you are missing some fundamental knowledge. Create a Chirpstack deployment, buy a couple devices and play around until you know what is necessary to accomplish your goal.
okay Thank you
I will go through in detail about these concepts…
Thank you
