nrf51822 password on characteristic

RE: nrf51822 password on characteristic

Joakim Jakobsen — Fri, 22 Dec 2017 09:46:00 GMT

This question has a duplicate with additional information.

RE: nrf51822 password on characteristic

Foxek — Thu, 21 Dec 2017 20:50:00 GMT

Thank you, I will consider this and choose the right solution

RE: nrf51822 password on characteristic

endnode — Thu, 21 Dec 2017 20:44:58 GMT

It's higher layer so whatever you consider as "authenticated" to perform (G)ATT action which is requested by the stack that it will be. Good thing: you can do whatever you want. Bad thing: you need to be damn sure what you are doing, you are on your own.

RE: nrf51822 password on characteristic

Foxek — Thu, 21 Dec 2017 20:42:43 GMT

how specifically does authentication work? By what principle does it allow / disallow devices?

RE: nrf51822 password on characteristic

endnode — Thu, 21 Dec 2017 20:40:49 GMT

It should work with Read/Write with authorization as per the message sequence chart. "Password and then you can do anything" isn't really secure but yes, it's slightly better then nothing. If this is enough for you it should work, sorry to pushing you to something more complex...

RE: nrf51822 password on characteristic

Foxek — Thu, 21 Dec 2017 20:34:29 GMT

I have a problem with the following character. I have two services. One device (administrator) must have access to one service, the other device (user) must have access to the other. Neither the user nor the administrator has access to someone else's service. there is a possibility to implement it on the stack or you will have to implement it in app?

RE: nrf51822 password on characteristic

endnode — Thu, 21 Dec 2017 20:28:11 GMT

Just to complete: if you are not using encrypted link that using passwords is useless because anyone with 40$ equipment will hear it in 20-100m diameter. If you are using properly secured link then why would you protect one part of the client from another when it must come from the same device? And if you don't trust each other then fine, deploy proper secure channel based on symmetric or asymmetric keys and not passwords, that should have died in 80s...

RE: nrf51822 password on characteristic

endnode — Thu, 21 Dec 2017 20:25:55 GMT

You are right, there exist two levels on (G)ATT layer: Authorization to Read/Write and Authentication to Read/Write. It seems that authorization is what you are looking for (that depends on App proprietary state and explicit permission to execute while the other should just relate to Link state - if it uses encryption or not). See GATT Server message sequence charts here. I've totally forgotten about these and reason probably is that I've never seen this in use. Passwords are adding typically almost no security at all so if you are not able to utilize BLE security inside the stack (e.g. because it doesn't scale to fleet of many devices) then you should design proper secure channel protocol on APP layer.

RE: nrf51822 password on characteristic

Foxek — Thu, 21 Dec 2017 19:04:26 GMT

And what about rd_auth/wr_auth?

RE: nrf51822 password on characteristic

Foxek — Thu, 21 Dec 2017 17:27:02 GMT

I write password in the WRITE characteristic and it NOTIFIES me with data if password is correct? thanks.

RE: nrf51822 password on characteristic

endnode — Thu, 21 Dec 2017 17:21:18 GMT

Basically yes, just translate it to language of (G)ATT methods such as Read/Write/Notify...

RE: nrf51822 password on characteristic

Foxek — Thu, 21 Dec 2017 17:15:33 GMT

That is, it is necessary to implement the response function at the application level. I write password to the character , and it gives me the data if the password is correct?

RE: nrf51822 password on characteristic

endnode — Thu, 21 Dec 2017 17:12:39 GMT

You can do whatever you want on APP layer so if you define protocol on top of that Characteristic and implement some password verification the it will work. On BLE level you have only Security Manager methods which restrict access to certain (G)ATT objects as per link (encrypted/unencrypted) status but that is global for the link and GATT Server, you cannot make it more granular and define some additional PINs or passwords for each object...