Vraag

Achterhouden AppSKey voor KPN in combinatie met OTAA

  • 7 oktober 2016
  • 4 reacties
  • 337 keer bekeken

Volgens het topic "Lora Decryption on Application Server" moet het mogelijk zijn om de AppSKey niet op te geven in Thingpark, zodat de applicatiedata op de applicatieserver zelf ontsleuteld moet worden en KPN dus niet over deze sleutel beschikt. Echter is bij OTAA de procedure dat aan de hand van de AppKey, de AppNonce, DevNonce en NetID aan beide kanten de NwkSkey en AppSKey worden berekend. In dat geval beschikt KPN dan toch alsnog over de AppSKey? Impliceert dit dat de mogelijkheid om de AppSKey achter te houden, enkel werkt in combinatie met ABP?

4 reacties

Reputatie 2
Badge +1
Scherp. Het klopt inderdaad dat in de huidige implementatie van OTAA de Join-server binnen het KPN netwerk staat en de AppSKey nog niet op een volledige juiste manier bij klanten terecht kan komen zonder dat KPN hierbij kan. 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.
Ok dat is duidelijk, bedankt!
Reputatie 1
Badge
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?
Reputatie 7
Badge +11
Beste @tonb, dat klopt inderdaad. Dit is voor de eenvoud gedaan.

Reageer