Reacties geplaatst door tonb

14 Reacties

R
RoelWesthoffStarter
gevraagd in LoRa Forum

Creating a payload

The uplink and location messages are two separate POSTs to your application server. I suspect you must look for the problem in your application server. You could try generating a POST endpoint using https://webhook.site and temporarily using that in the KPN portal (as a replacement of your application server URL), then you can see the raw messages coming in in real-time.

4
R
5 jaar geleden
R
RoelWesthoffStarter
gevraagd in LoRa Forum

Creating a payload

The message you included is the location message. There should be another message [b]preceding [/b] it, with DevEUI_uplink in stead of DevEUI_location. This message will a.o. contain the field "payload_hex" with your payload expressed as a hexadecimal string.

4
R
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

[quote=Tim B]Beste tonb, Vanaf buiten het netwerk is het echter niet mogelijk te achterhalen of een device een FCntUP=0 verstuurt of een FCntUP=811, immers is het bericht encrypted en onleesbaar.[/quote] Weet je zeker dat de framecounter ge-encrypt is? Volgens de spec wordt alleen de FRMPayload geencrypt, en DevAddr en FCnt zitten daar buiten. Een eavesdropper kan dan gemakkelijk meetellen, toch?

8
T
KPN Moderator
5 jaar geleden
tonb
tonbActieve Deelnemer
gevraagd in LoRa Forum

LoRaWAN v1.1 support

Ik begrijp dat de roadmap niet openbaar is. Voor toepassingen, waarbij security en privacy belangrijk zijn, is het natuurlijk wel belangrijk om te weten hoe de situatie over, zeg, een jaar is. Over de verschillen: De OTAA procedure levert een hoop meer keys op. Waar je bij v1.0 met als input een DevEUI en een AppKey (en twee nonces) een NwkSKey en een AppSKey afleidt, is het uitgangspunt bij v1.1 een DevEUI, AppKey en NwkKey. De sleutels die uiteindelijk ontstaan zijn JSIntKey, JSEncKey, AppSKey, FNwkSIntKey, SNwkSIntKey en NwkSEncKey. Nu kan encryptie en integrity checking met verschillende sleutels gedaan worden, waardoor de keys op een need-to-know basis aan de diverse server bekendgemaakt kunnen worden, zodat je end-to-end security in combinatie met bv. roaming kunt realiseren.

2
tonb
5 jaar geleden
Sander-IoT
Sander-IoTNieuwkomer
geplaatst in LoRa Forum

HTTP integration van TTN

Is dit niet gewoon de [b][i]enige [/i][/b] methode die KPN ondersteunt (al sinds het begin)?? (Met als "limitatie" dat het https moet zijn). Of mis ik iets...

4
Tim
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

Kun je de exacte werking van dit algoritme toelichten? Ik zie dat als ik een device bij FCntUp=0 laat beginnen, en dan berichten laat zenden met waardes 1,2,3,4,... dat ze allemaal binnenkomen. Als ik 'm reset komen de berichten met 0,1,2,34,... wederom netjes door. Betekent dit dat aan server zijde de teller ook gereset wordt? Als dat zo is, zou men dan door het FCntUp=0 pakket te replayen, de "echte" node kunnen blokkeren?

8
T
KPN Moderator
5 jaar geleden
J
Jim_GBStarter
gevraagd in LoRa Forum

Informatie post request incorrect

Jim, De data die je noemt lijkt meer op de querystring dan op de body van de POST. De query string gegevens zijn alleen nodig om ter authenticatie; door het Token na te rekenen kun je vaststellen of de POST van KPN afkomstig is. In jouw screendumps zie ik de LoRa JSON structuur (met payload_hex) gewoon zitten. Volgens mij hoeft er niets gedecrypt te worden. Alleen je payload_hex (in jouw screendump 0xe39a66) moet gedecodeerd worden. groeten, Ton.

6
Rick S.
Community manager
5 jaar geleden
Lennart Nordin
Oud KPN Medewerker
Lennart NordinOud KPN Medewerker
geplaatst in LoRa Forum

LoRaWAN Security: Encryption and Authentication

Last year in this topic (https://zakelijkforum.kpn.com/lora-forum-16/achterhouden-appskey-voor-kpn-in-combinatie-met-otaa-8459) it was mentioned that: [i]Het streven is een oplossing waarbij OTAA zo ingericht is dat end-2-end encryptie mogelijk is. Hierin moeten nog architectuur keuzes gemaakt worden en het resultaat hiervan zal worden meegenomen in een volgende release.[/i] Has there been any progress in this area since then, in other words, is there an OTAA scheme possible whereby KPN does not 'see' the AppSKey? I believe a separate 'join-server' is needed?

13
Lennart Nordin
Oud KPN Medewerker
5 jaar geleden
R
rikvdhNieuwkomer
gevraagd in LoRa Forum

Validatie Tokens van DevEUI_location en DevEUI_downlink_Sent berichten

Ik heb nog een vraag, of eigenlijk eerder een observatie m.b.t. de casing van het DevEUI voor validatie met het token: Bij DevEUI_uplink berichten worden de DevEUI in de body en de LrnDevEui in de querystring beiden in [b][u]uppercase [/u][/b]gestuurd. Dit moet je zo laten aangezien de token blijkbaar ook met een uppercase DevEUI is berekend. Bij DevEUI_location berichten wordt de DevEUI in de body in [b][u]uppercase[/u][/b] verstuurd, maar de LrnDevEui in de querystring in [b][u]lowercase[/u][/b]. Hier moet je de body DevEUI naar [b][u]lowercase[/u][/b] converteren voor een correcte validatie (zoals eerder in deze thread al opgemerkt). Erg consistent is dit niet... - Zijn hier bug-fixes te verwachten? - Is het verstandig om een bepaalde casing te forceren om aan validerende kant ongevoelig voor KPN wijzigingen te worden? - Zijn er nog meer velden die onderhevig zijn aan case wijzigingen? Onze AS_ID is toevallig helemaal lowercase.

13
tonb
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

Ik wil wat metingen doen naar de nauwkeurigheid van LoRa geolocation onder diverse omstandigheden. Is er nog een verschil in te verwachten nauwkeurigheid tussen de developer portal en het productie Thingspark? Tweede vraag: zijn er plekken in Nederland waar de verwachte nauwkeurigheid "bovengemiddels hoog" is?

59
Rick S.
Community manager
6 jaar geleden
michieljol
KPN Moderator
michieljolProductmanager LoRa for Developers
geplaatst in LoRa Forum

Uplink and downlink messages signed with SHA tokens

[quote=jwktje]I have the same problems as Kees DPD. The "Test Uplink" always fails no matter what I use as ASKey variation. I have tested with the exact reference code mentioned by Lennart Nordin but still no luck. And I agree it is probably to do with the time format that is wrong. Any fixes for this?[/quote] Hi, It is true that the token sent with the "Test Uplink" button, fails the validation. But for regular LoRa messages the validation is quite straightforward. Below is a node.js snippet that works for me. The AS_ID is used unmodified (ie., keeping the dashes). [code] const crypto = require('crypto'); function ValidateSender(query, body) { let queryParams = `LrnDevEui=${query.LrnDevEui}&LrnFPort=${query.LrnFPort}&LrnInfos=${query.LrnInfos}&AS_ID=${query.AS_ID}&Time=${query.Time}`; let bodyElements = body.CustomerID+body.DevEUI+body.FPort+body.FCntUp+body.payload_hex; const hasher = crypto.createHash('sha256'); hasher.update(bodyElements + quer

12
Tim
6 jaar geleden
I
IASRijzende ster
gevraagd in LoRa Forum

Test uplink error: javax.net.ssl.SSLException hostname in certificate didn't match: != OR OR

I'm experiencing trouble when using an endpoint hosted on Amazon's AWS API Gateway. [i]Response info: Error in sending rest post to developer url https://xxxxx.execute-api.eu-central-1.amazonaws.com/test/lora, for device xxxxxxxx, payloadhex 000000. Error details: javax.net.ssl.SSLHandshakeException Received fatal alert: handshake_failure[/i] From reading above posts, the most probable cause is the improper support for SNI by KPN, is that a correct assumption?

24
Rick S.
Community manager
6 jaar geleden
D
Dik-JanNieuwkomer
gevraagd in LoRa Forum

SSL exception tijdens het versturen van een UpLink bericht

Ik probeer een Amazon Web Services endpoint (API Gateway) te gebruiken en krijg in de developer portal een soortgelijke foutmelding: javax.net.ssl.SSLHandshakeException Received fatal alert: handshake_failure De certificates zijn volgens digicert wel in orde. De foutmelding lijkt gerelateerd te zijn aan het onderhandelen van de juiste ciphersuite of het gebruik van SNI (Server Name Indication). Geen idee. Maar wel jammer dat dit niet werkt! Iemand een tip?

8
Rick S.
Community manager
6 jaar geleden
R
robkleineeDeelnemer
gevraagd in LoRa Forum

Achterhouden AppSKey voor KPN in combinatie met OTAA

Vraagje hierop voortbordurend: aangezien de message integrity gecheckt wordt met de NwkSKey, kan de netwerkprovider theoretisch dus wel de encrypted payload veranderen, dus confidenciality is gegarandeerd maar integrity is een kwestie van vertrouwen?

4
Tim
7 jaar geleden

Badges

Toon alle badges
Forumvoorwaarden