Ble non discoverable

[Nadeem]

Dear all,

Is it possible to:

1. Make a ble central which is just recieving advertising data , but not visible by sniffers and etc.

2. We want o use the nrf52 for a id system.. it needs to be secure and seemless.  Hence we dont want the user to need to pair. We want him to just turn on his app and automaticaly the ble central picks up the id being advertised by the phone.. as the data being sent is very small we were thinking of just encrypting the data and putting it in a advertising packet.

3. Is it possible to encript the entire advertising packet?

Look forward to here some feed back and advice. Thanking you.

Nadeem jamal

[ovrebekk]

Hi Nadeem

You can't make the entire advertise packet invisible, so a sniffer would be able to see that something is being sent, but it is possible to encrypt the data content of the advertise packet. 

The main challenge is that you will lose quite a bit of the 31-byte advertising payload since adding encryption will add overhead. Typically you will need some form of counter in the payload (to avoid replay attacks), and a MIC/authentication field to avoid man in the middle attacks. 

You might also a key index in the packet so that you can use multiple keys, to prevent someone from compromising the entire system if they get a hold of one of the encryption keys (ideally you want device independent keys, but this might be hard to do in practice). 

So to summarize, yes, this is possible, but perhaps not very straight forward ;)

Best regards
Torbjørn

[Nadeem]

HI Torb,

Thwnks for ur reply.

Im still confused about how to go about it...is it possible to pair my central and peripheral device securely without the user havng the need to enter authorization pin.. if so how?

Another thing was suppose we were able to pass the central and peripheral a passkey from a seperate channel like for example, for exaple tcp ip.

Thanks,

Nadeem

[ovrebekk]

Hi Nadeem

You are hinting at the answer. If you need to be protected against man-in-the-middle attacks you need to do some form of authorization, and if you are unable to do manual pin entry then you need to provide authorization data out of band (OOB). 

A potential way to do this is to program some unique authorization data into each device in production, and make this data available to the phone app through a cloud backend, but this will obviously complicate the production and management of your devices considerably.

NFC is a simpler OOB solution that doesn't require you to pre-program the devices with authorization data, but this requires you to use a phone that supports NFC Bluetooth pairing. 

Whichever way you choose an issue is that iOS doesn't support NFC or OOB pairing, and requires you to manually input or confirm a passkey if you want to use authorized pairing. 

Best regards
Torbjørn

[Nadeem]

Hi Guys ,

I am still confused on what kind of encryption to use.. I basically have the whole 16 bytes of UUID in the advertising packet free to use...

Through our servers using TCP/IP, we will send the encryption Key to both the app and the nrf device. The data we need to encrypt is very small only max 6 bytes at most.

I have been playing around with encryption simulators online all of them require the ciphertext to increase allot due to overheads.. For example, the CBC Mac requires a lot more than 16 bytes to be transferred. 

I thought AES CTR might work but someone told me that also need to be 128 bit in NRF.

Can anyone advise which encryption I can use so it will fit easily in the 16 bytes I have for Cipher text and overheads?

Thanking you

Nadeem Jamal

[ovrebekk]

Hi Nadeem

Are you sure you only can spare 16 bytes in the advertise packet?

What else do you need to add to the advertise packet other than the encrypted payload?

If you use the manufacturer specific data field (0xFF) you can essentially put 29 bytes of user data in one advertise packet, and you can format it any way you like. 

Since AES 128 works on a block size of 16 byte it is hard to get the encrypted payload any smaller than this, and you normally need a MIC field on top of this to verify the integrity of the encrypted payload. 

Another option might be to have the scanner send a scan request, allowing the advertiser to send two distinct 31 byte payloads. 

Best regards
Torbjørn