Most recent activity
-
Hi @cefitzger, ~afaik Bluez is used in android~ (wrong, it used to be up until 4v). Anyways, I wonder what happens when you
NRF.setSecurity({lesc: 1});and then manually initiate bonding? This flow (central initiated) could be different to the one that you are trying to do (when peripheral responses with an error and then central automatically initiates secure connection). I'm just trying to narrow it down, there might be nothing to do with characteristic security. -
From your WireShark trace, when secure request is made, your central provides "SecureConnection, MITM & Bonding" auth parameters. I'm just guessing that this is what your central wants to have, i.e. it is requesting to establish secure link with MITM and also store keys. I'm speculating again, this list of parameters is made by Bluez based on peripheral advertisement packages (which contains some capabilities flags). I think your central (bluez) does not specify lesc parameter just because it does not know if your peripheral supports it, It could be that you have to set up your peripheral to advertise lesc capability so that Bluez knows what to do.
Can you please try to set this?
NRF.setSecurity({lesc: 1});I assume that this will make your peripheral to advertise that it supports lesc and give a hint for Bluez to try to use lesc algorithm.
-
Hi @fanoush,
What if I wanted to communicate with e.g. 20 sensors without pairing/bonding them all but still wish to have the link encrypted like https does, is this scenario supported in BLE?
Yes, this is a valid use case. You may establish secure connection without actually bonding (think about it as a temporary bond). This is what happens when you mark characteristics as secured, but you do not initiate bonding. Bluez in this case automatically "starts" temporary secure connection and also automatically performs failed operation (read or write) with the same payload. Bear in mind that it is not very secure anyway as centra and peripheral have to exchange secure keys every time they establish connection, hence it is prone to mitm attack.
Some good readings on that topic: https://gattack.io/
Have a look at the whitepaper that describes many possible attacks: https://github.com/securing/docs/raw/master/whitepaper.pdf
-
Hi @cefitzger thanks for your feedback.
I agree it might be confusing, but not all combinations of security params are valid, e.g. some of them are mutually exclusive. If you set "lesc" to true, then all other parameters get ignored. I've tried to describe this in the documentation here: https://www.espruino.com/Reference#l_NRF_setServices
Note: Not all combinations of security configuration values are valid, the valid combinations are: encrypted, encrypted + mitm, lesc, signed, signed + mitm.Effectively all your tests were done using "lesc". Not all BT devices support this security protocol, I think it has been introduced in BT 4.2 specification. I assume one of your android device, ios or pixl itself does not support it, hence fails establishing security channel.
I did some test using a sniffer (nrf51822 and android 7.x), what I saw is similar to your WireShark trace, but after a successful pairing response I saw that all data packages were encrypted, I could not even see what type of packages get exchanged, e.g. the software I used could not decode radio packages.
Re rationale of having security configs per each characteristic. I agree this might be confusing, but if you consider characteristics as abstract resources, then why would not you have different levels per each? I can make up an example. Let's say you have a peripheral device that can report some data which is not secure (open). You may connect to it and read that data, you may chose not to establish or not to establish secure channel (pair or not pair), this is a valid case. But also that device provides a characteristic that is used to change some settings, this one has to be secured hence you mark it as secured, i.e. forcing central to establish secure connection just for this characteristic. I think it makes perfect sense having different levels per each characteristics (and not globally).
-
-
Just thinking about the structure more, I think it is better to have something like that:
NRF.setServices({ 0xBCDE : { 0xABCD : { value : "Hello", readable: true, writable : true, security: { read: { encrypted: false, mitm: false, lesc: false, signed: false }, write: { encrypted: true, mitm: false, lesc: false, signed: false } } } } });Here is my branch it is still in wip and untested.
@cefitzger, I use docker to build espruino firmware. It is a mater of 10 mins to install docker daemon and you have a proper stable environment. More details here: https://github.com/espruino/Espruino/blob/master/Dockerfile
Once you've build it first time, you can then use this docker file to speed up the process (it will just copy sources and won't install build chain):