• State Verified Answer
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 451 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 244949
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Authenticate connected App

Ingfu

Hi,

we have developed a device with the nRF52832 that conncects with an Android smartphone. Our connection is secured and encrypted.

However, that doesn't really prevent the reverse engineering of our App, so that a 3rd party App also could make a connection to our device.

Is there a built-in mechanism or general approach to authenticate or verfiy the connection with our App?

Cheers

Parents
  • +1

    Hi,

    As I understand, you trust that there are only authentic nRF devices, but you want to make sure that the smartphone app is also authentic. This is similar (but opposite) to the problem device manufacturer that wants to add clone protection to their devices.

    There is no built-in mechanism for handling this, but I suggest you use a scheme centered around a challenge-response authentication. This can be done in many ways, with pros and cons with regards to security, complexity, and user-friendliness. How paranoid are you?

    1. If you just want to make it slightly difficult, you could use hardcoded keys in your phone app and nRF device. The key in the nRF device can be fairly well protected using readback protection. The key in the app, however, would be easy to extract for an attacker. If that is not a problem, then you could simply use a challenge-response exchange using the hardcoded keypair. In this simplistic approach, there will not be any information transmitted on air that can be used to compromise the device, but the phone app is a very weak point. In many cases, this will probably be good enough.

    2. If the nRF is internet-connected (usually not the case), then you could provision each app in some way, and the nRF would use a challenge-response authentication against the app. In this case, you would use a textbook clone protection sceme, just the other way around.

    3. If the phone is internet-connected and you want a solution with more security you could do something like this:

    • Authenticate the app against your cloud service somehow and provision the app with an asymmetric key.
    • nRF communicates with your cloud service via the app, but with data that is encrypted using an asymmetric key pair that was provisioned during production so that the phone app itself cannot read or manipulate the communication. The cloud provides the nRF with the corresponding asymmetric key.
    • The nRF uses this key to provision the app.

    You could think of ways to avoid the mechanisms in this case as well, but that could be avoided by adding, for instance, the requirement to refresh keypair via the cloud service every x reconnect etc.

Reply
  • +1

    Hi,

    As I understand, you trust that there are only authentic nRF devices, but you want to make sure that the smartphone app is also authentic. This is similar (but opposite) to the problem device manufacturer that wants to add clone protection to their devices.

    There is no built-in mechanism for handling this, but I suggest you use a scheme centered around a challenge-response authentication. This can be done in many ways, with pros and cons with regards to security, complexity, and user-friendliness. How paranoid are you?

    1. If you just want to make it slightly difficult, you could use hardcoded keys in your phone app and nRF device. The key in the nRF device can be fairly well protected using readback protection. The key in the app, however, would be easy to extract for an attacker. If that is not a problem, then you could simply use a challenge-response exchange using the hardcoded keypair. In this simplistic approach, there will not be any information transmitted on air that can be used to compromise the device, but the phone app is a very weak point. In many cases, this will probably be good enough.

    2. If the nRF is internet-connected (usually not the case), then you could provision each app in some way, and the nRF would use a challenge-response authentication against the app. In this case, you would use a textbook clone protection sceme, just the other way around.

    3. If the phone is internet-connected and you want a solution with more security you could do something like this:

    • Authenticate the app against your cloud service somehow and provision the app with an asymmetric key.
    • nRF communicates with your cloud service via the app, but with data that is encrypted using an asymmetric key pair that was provisioned during production so that the phone app itself cannot read or manipulate the communication. The cloud provides the nRF with the corresponding asymmetric key.
    • The nRF uses this key to provision the app.

    You could think of ways to avoid the mechanisms in this case as well, but that could be avoided by adding, for instance, the requirement to refresh keypair via the cloud service every x reconnect etc.

Children
No Data
Related
Terms of service