The Replay Attack Prevention mechanism enhances the network security

  • 4 April 2018
  • 8 reacties
  • 788 keer bekeken

Reputatie 3
Badge
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 resetten van de counter in je device is niet volgens de LoRa-specificaties, maar het werd tot voor deze update gedoogd. Omdat we met de steeds groter wordende groep gebruikers het netwerk ook veiliger willen maken, hebben we deze Replay Attack Prevention ingeschakeld.

---------------------------------------------

With the latest update of ThingPark, version 4.3, a Replay Attack Prevention mechanism was introduced in our network. This mechanism uses the frame counter (FCntUp) to determine whether an incoming message is valid. In case a new message with the same counter as the previous message is sent, then this message is ignored. This functionality applies to both ABP- and OTAA-devices.

As a result of this mechanism, it is no longer possible to turn devices off after every message without storing the counter-value. Since switching the device off resets the counter value, the device will only send messages with FCntUp=1. This means that all messages will be ignored by the network, which results in messages of the device that are no longer sent to the Application Server. The Alarms-page in ThingPark will show warnings indicating a frame replay is blocked. Constantly resetting the counter of a device is not in accordance with the LoRa-specifications, and up until now this was tolerated. The Replay Prevention Mechanism was implemented to increase the safety of our network and its growing user group.

8 reacties

Hi Lennart,
Is bovenstaande alleen van toepassing op devices die starten op FCntUp = 1?
Devices die (na het verwisselen van batterijen) opnieuw starten met een FCntUp = 0 (LoRaWAN 1.0.2) worden niet geblokkeerd als replay attack?

UB
Reputatie 3
Badge
Hi Ultiblade,

Devices die met FCntUp = 0 sturen zouden hier inderdaad geen problemen van moeten ondervinden.

Groet,
Lennart
Hi Lennart,

Bedankt! Fijn dat devices die starten op FCntUp = 0 niet in de problemen zullen komen.

Als ik het nog eens doorlees vraag ik me het volgende nog af: gaat het nu eigenlijk alleen om devices die steeds herhaaldelijk iedere uplink met een FCntUP = 1 starten of worden devices die na een tijdeje berichten sturen en, met bijvoorbeeld een FCntUP = 1328, opnieuw starten door een batterijwissel ook geblokkeerd?

Groet,
UB
Reputatie 3
Badge
Hi ultiblade,

Excuus voor het niet eerder reageren op je bericht, deze was er tussendoor geglipt.
Met betrekking tot je vraag, berichten die met eenzelfde framecount worden verzonden als een eerder bericht die zullen worden geblokkeerd (dus ook een bericht met FCntUp=1328, als het vorige bericht ook die framecount had). Als er vervolgens een bericht met een hogere framecount verstuurd wordt, dan komt dat bericht wel weer door.
Een device wordt dus niet geblokkeerd, maar specifieke berichten kunnen wel worden tegengehouden.

Groet,
Lennart
Reputatie 1
Badge
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?
Beste tonb,

Aan de serverzijde wordt gekeken of er een logische opvolging zit in de frame counters. Als er een FCntUP=0 wordt gestuurd, gaat de server ervan uit dat het device is gereset en begint deze opnieuw met tellen. Zoals aangegeven dient het resetten van de counter vermeden te worden, om zodoende de juiste security te behalen.

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. Het enige wat vanaf de buitenkant mogelijk is, is het herhalen, oftewel 'replayen' van een bericht dat verzonden wordt nadat dit is opgevangen in de lucht. Deze replays worden vanaf heden geblokkeerd, aangezien zij gebruik maken van dezelfde FCntUP als het eerder verzonden bericht. Additioneel word je gewaarschuwd dat er mogelijk replay attacks plaatsvinden, zodat daar actie op ondernomen kan worden.
Reputatie 1
Badge
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.


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?
Beste tonb

Ik gaf het antwoord misschien wat te snel en daardoor kort door de bocht. Wat ik probeerde aan te geven is dat indien de FCnt opgepikt wordt door een eavesdropper, hier niet veel meer mee gedaan kan worden, zelfs al zou je kunnen doortellen. Immers zou de integriteit van een bericht nooit kloppend gemaakt kunnen worden zonder de beschikking te hebben over de juiste NwkSKey.

Reageer