Unique Id of a device needed

[marko]

Hi​,

I am looking for the possibility of getting an unforgeable unique ID of a bonded device within a BLE connection. Using nRF51422 with SD310 for the peripheral, any smartphone or tablet for the central is intended.

After a peripheral has been bonded to a central device, the peripheral will offer some data. But offering data should only happen, when the central device has informed the peripheral about his identity. This ID information must not be stored in the centrals application because it is not possible for us to secure this ID. So it is necessary to use some kind of device identifier, which is coupled to the hardware, but not changeable by users.

The intention is that there are few specified central devices and thousands of peripherals. All these peripherals are connectable to any central and give some information. But for the few specified centrals they will grant access to deeper information. Which token of the BLE connection could I use?

First I wanted to use the MAC address but it did not work because it could change. The difficulty is to find somewhat which is not able to be manipulated by the centrals application. Even if the centrals application is copied to another central, the unique ID should be useless. Therefore I want to use some hardware-coupled ble specific token.

I would appreciate if someone can help me! Thanks a lot.

Best Regards, Marko

[Ulrich Myhre]

Hi,

There have been some questions about this earlier:

devzone.nordicsemi.com/.../

devzone.nordicsemi.com/.../

The take-away is that there are no identifiers that are guaranteed to be unique in the chip's factory registry. They are randomly generated however, so it is quite unlikely that they will be re-used. DEVICEID, DEVICEADDR, ER and IR are all randomly generated (except 2 bytes of DEVICEADDR for the address type) and together these could make do as a likely unique identifier.

These values are also not possible to change.

[marko]

Hi, I already had read this questions and still there are some more I read. But they did not solve my problem. If you read my question then you will see that the problem is not to get an identifier out of a nRF51422. It is about to identify the central device as seen from the perspective of the nRF51422 peripheral. So I am looking for a token related to the BLE connection, and this token should not be able to be manipulated by software. Regards, Marko

[ovrebekk]

Will the central devices be Nordic based as well, or could any BLE central be used?

[marko]

For the central any smartphone or tablet is intended. It is beyond our control so there could be everything beside a Nordic based device.

[Ulrich Myhre]

Thank you for clarifying, I thought you had control of the central in this scenario. Unfortunately, there are no identifiable parameters to a connection that cannot be changed by the peer. The closest is probably reading the remote version, but this is a link-layer feature - often not visible to the app. It is also the same value for all devices using the same SoftDevice version. But even here there could be "rogue" peers that will fake this value if they need to.

It's possible that you will have to implement some application security layer yourself, using a verified cryptographic scheme. This requires you to have an application that supports it on both sides, however.

[marko]

Thanks for your answer. I checked the link layer capabilities carefully but there does not seem to be a feature I can use. Indeed I have to implement my security functionality on application layer and this was planned too. But therefore I need this unique device ID. I further think about using the BT device address. After bonding even a private address is resolvable to the original device address if I'm right. So the question is, is it possible to use a counterfeit address for let's say an Android app? On the other hand, if I only use the application layer for authentication (without a device specific token) then copying this android app will copy the unique ID in this app. Even if the ID is not stored in the android app code then it seems to be easy to decompile android app and get info about where the ID is taken from. I heard, the android java code is not really safe