Beantwoord

FcntUp 16 bit wrap icm decryptie op eigen application server: hoe kom ik aan de volledige 32 bit waarde?

  • 19 March 2019
  • 10 reacties
  • 1010 keer bekeken
T
De fcntup teller in onze lorawan stack (gebaseerd op semtech loramac-node) is 32 bits. De fcntup velden in de lora communicatie zijn 16 bits, terwijl de encryptie en bepaling van de mic op basis van de volle 32 bits waarde gebeurt. Dit betekent dat het netwerk (dwz de gateway en de application server) de hoogste 16 bits niet uit de berichtdata zelf kan halen, en (soms) zal moeten uitproberen; wanneer de teller de 0xffff gepasseerd is, kan een daarop volgende lage fcntup waarde wijzen op een 16 bit wrap, of op een device reset.

De LRC kan waarden uitproberen om te zien bij welke waarde voor de hoogste 16 bits van de fcntup de mic klopt: een harde check. De application server heeft die mogelijkheid niet, wanneer de payload geen redundante informatie bevat die daarvoor gebruikt kan worden.

Aangezien het netwerk de data aflevert aan onze application server, na validatie van de mic, heeft de LRC per definitie weet van de volledige fcntup waarde. Is er een mogelijkheid voor de application server om deze voor mic validatie gebruikte 32 bit waarde te weten te komen?
icon

Beste antwoord door Rick S. 15 April 2019, 13:52

Bekijk origineel

10 reacties

Rick S.
Rank
Reputatie 7
Badge +6
Goedemorgen @thingsconnected ,

Welkom bij de IoT Community!
Ik moet eerlijk zeggen dat ik uw vraag niet helemaal kon volgen. Ik ben daarom allereerst op zoek gegaan naar uw account in de Developer Portal. Daar kon ik u niet vinden en heb mij toen tot onze specialisten gericht. Ik kreeg vervolgens onderstaande terugkoppeling:

Als een device communiceert met de LRC, wordt op basis van uitgewisselde informatie tijdens de join procedure op beide domeinen een NwkSKey gegenereerd. (device en LRC). Deze NwkSKey zal ook alleen maar bekend blijven op de LRC en op het device.

Deze NwkSKey wordt in het berichtverkeer vervolgens gebruikt om een MIC te genereren die vervolgens weer gebruikt wordt om de integriteit van elk bericht te kunnen laten verifiëren door de ontvanger (de LRC in geval van uplink en het device in geval van downlink). In geval van de uplink: na verificatie dat het bericht van device naar LRC daadwerkelijk correct ontvangen is, wordt het bericht zonder MIC verder gestuurd naar de Application Server. De Application Server en gateway hebben dus geen noodzaak voor het kennen van de MIC of NwkSKey. Deze MIC is dus ook niet te achterhalen door een Application Server, omdat dit de security van de communicatie kan aantasten.

Is uw vraag hiermee beantwoord?
Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -
T
Beste Rick,

Dank voor je antwoord. Helaas is mijn vraag nog niet beantwoord. Wij hebben alleen een account op de deviceManager en de wLogger, onder onze bedrijfsnaam Things Connected.

Bij de berekening van de MIC wordt ook gebruik gemaakt van de FcntUp waarde, dat is de berichtenteller. Die is 16 bits groot (waarde 0 tot 65535) in de communicatie, maar 32 bits groot (waarde 0 tot 2^32-1) intern, wanneer die gebruikt wordt voor berekening van de MIC (en voor encryptie van de payload). Zie bijvoorbeeld in de semtech stack:

voor de MIC, https://github.com/Lora-net/LoRaMac-node/blob/develop/src/mac/LoRaMacCrypto.c, regel 398:
code:
static LoRaMacCryptoStatus_t PrepareB0( uint16_t msgLen, KeyIdentifier_t keyID, bool isAck, uint8_t dir, uint32_t devAddr, uint32_t fCnt, uint8_t* b0 )  {
...
    b0[10] = fCnt & 0xFF;
    b0[11] = ( fCnt >> 8 ) & 0xFF;
    b0[12] = ( fCnt >> 16 ) & 0xFF;
    b0[13] = ( fCnt >> 24 ) & 0xFF;


voor de payload encryptie, zelfde file, regel 256:
code:
static LoRaMacCryptoStatus_t PayloadEncrypt( uint8_t* buffer, int16_t size, KeyIdentifier_t keyID, uint32_t address, uint8_t dir, uint32_t frameCounter )
...
    aBlock[10] = frameCounter & 0xFF;
    aBlock[11] = ( frameCounter >> 8 ) & 0xFF;
    aBlock[12] = ( frameCounter >> 16 ) & 0xFF;
    aBlock[13] = ( frameCounter >> 24 ) & 0xFF;


De netwerkserver heeft een correcte waarde voor de hoogste 16 bits (anders lukt MIC validatie niet), en die zou ik graag ontvangen in de applicatie server, zodat ik daar niet (opnieuw) hoef te analyseren wat de meest waarschijnlijke waarde is.

Een heel eenvoudige oplossing zou zijn als de netwerkserver de volledige 32 bit waarde door zou zenden naar de applicatieserver, in plaats van de huidige 16 bits waarde.
Rick S.
Rank
Reputatie 7
Badge +6
Goedemorgen,

Bedankt voor uw terugkoppeling!
Balen om te lezen dat dit nog niet het juiste antwoord is. Gezien mijn eigen beperkte kennis op dit gebied heb ik ook uw terugkoppeling weer uitgezet, om te voorkomen dat ik zelf verkeerde info verstrek.

Als ik een terugkoppeling ontvang speel ik dit uiteraard direct weer door naar u!
Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -
T
Voor de volledigheid, de LoRaWAN v1.0.3 spec zegt o.a. dit over fcntup en 16/32 bits.

https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf, p. 19, regels 531-533:

code:
Note: Since the FCntfield carries only the least-significant 16 bits of the 32-bits frame counter, the server must infer the 16 most-significant bits of the frame counter from the observation of the traffic.


Aangezien op netwerkniveau de 16 most-significant bits al bepaald zijn, zou ik die graag ontvangen op de applicatieserver, zodat ik me daar niet druk hoef te maken om detectie van fcntup roll-over.

(LoRaWAN v1.1 bevat dezelfde passage, https://lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf p.23, regels 666-668)
Rick S.
Rank
Reputatie 7
Badge +6
Goedemorgen @thingsconnected ,

Ik heb zojuist weer een terugkoppeling van de specialisten ontvangen en zij komen er eerlijk gezegd ook niet helemaal uit.
Wij gaan de vraag daarom verder doorzetten naar de leverancier. Zij kunnen dit tot de bodem onderzoeken en ons verder helpen. Dit betekent alleen wel dat nog een paar dagen kan duren voordat we een terugkoppeling hebben.

Ik houd u op de hoogte!
Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -
Rick S.
Rank
Reputatie 7
Badge +6
Goedemiddag @thingsconnected ,

Allereerst mijn excuses voor mijn zeer late terugkoppeling!
De vraag is langs veel schijven gegaan, maar ik heb een terugkoppeling ontvangen:

Onderstaand een voorbeeld zoals de data ontvangen wordt vanuit de LRC wanneer de counter voorbij gaat aan de ~65k berichten. Hierin is te zien dat op dit moment de 32 bit waarde (FCntUp = 143689) wordt afgeleverd aan de applicatieserver. Beantwoord dit uw vraag?

{"DevEUI_uplink": {"Time": "2019-04-15T08:40:00.349+02:00","DevEUI": "XXXXXXXXXX","FPort": "2","FCntUp": "143689","MType": "2","FCntDn": "48862","payload_hex": "fe","mic_hex": "5974b257","Lrcid": "0059AC01","LrrRSSI": "-110.000000","LrrSNR": "2.000000","SpFact": "7","SubBand": "G0","Channel": "LC1","DevLrrCnt": "3","Lrrid": "FF010122","Late": "0","LrrLAT": "52.220467","LrrLON": "6.893251","Lrrs": {"Lrr": [{"Lrrid": "FF010122","Chain": "0","LrrRSSI": "-110.000000","LrrSNR": "2.000000","LrrESP": "-112.124428"},{"Lrrid": "FF0105BD","Chain": "0","LrrRSSI": "-113.000000","LrrSNR": "-3.000000","LrrESP": "-117.764351"},{"Lrrid": "FF0106EF","Chain": "0","LrrRSSI": "-114.000000","LrrSNR": "-6.000000","LrrESP": "-120.973228"}]},"DevLocTime": "2019-04-15T08:38:59.649+02:00","DevLAT": "52.203136","DevLON": "6.860087","DevAlt": "0.000000","DevAcc": "0.000000","DevLocRadius": "182.912582","DevAltRadius": "0.000000","DevUlFCntUpUsed": "143688","DevLocDilution": "0.067608","DevAltDilution": "0.000000","DevNorthVel": "0.000000","DevEastVel": "0.000000","CustomerID": "XXXXXXX","CustomerData": {"alr":{"pro":"Static","ver":"1"}},"ModelCfg": "0","InstantPER": "0.000000","MeanPER": "0.000010","DevAddr": "XXXXXX"}}
Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -
T
Beste @Rick S.

Dank voor het antwoord! Dat ziet er goed uit, helaas ontvangen wij dit niet. Wij krijgen een xml feed met de 16 bit waarde. Hoe komen wij aan deze json feed?
Rick S.
Rank
Reputatie 7
Badge +6
Goedemiddag,

De wijze van hoe berichten ontvangen worden door de applicatieserver (JSON/XML) kan ingesteld worden bij het aanmaken/editen van de applicatieserver in de ThingPark Device Manager.

Indien het ook dan blijft voorkomen dat berichten slechts in 16 bit blijven binnenkomen lijkt me de beste route om een ticket aan te maken via de Service Portal om onze experts dieper in dit probleem te laten duiken.
Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -
T
Dank!
Rick S.
Rank
Reputatie 7
Badge +6
Heel erg graag gedaan hoor!

Als u nog andere vragen heeft, u kunt altijd hier op het forum terecht 😁
Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -

Reageer


Forumvoorwaarden