Nontraditional pairing using certificates/PKI

RE: Nontraditional pairing using certificates/PKI

Einar Thorsrud — Wed, 29 Jan 2020 12:32:59 GMT

Hi Jay,

I see. The way I understand it this should work well with your authentication on top of LESC just works pairing. Then after pairing you can do your authentication procedure, and disconnect if authentication fails.

[quote user="jaylong"]Thanks for the info on LTK etc. I'm sure this is well documented but if you have any good primers I'd be happy to get links.[/quote]

The short story is that LESC uses Diffie–Hellman key exchange and derives the LTK from the shared secret. The LTK is subsequently used to encrypt the link for all future connections. I don't know of a good primer, but the principle is quite simple. You can refer to BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 3, Part H SECURITY MANAGER
SPECIFICATION (starting at page 2417) for all details.

Einar

RE: Nontraditional pairing using certificates/PKI

Jay — Wed, 29 Jan 2020 02:03:19 GMT

Thanks for the thoughtful response Einar,

To answer your questions:

1. Any two devices will need to be able to pair. No pairing will be done at time of manufacturing.
2. Only the hub device will have internet access and hence access to the full PKI in "real-time". The peripheral will only have internet access through the hub. While traditional TLS only stores the root public key, fetching the subsequent nodes in the certificate chain in real-time, I believe we can overcome this real-time limitation by storing the full public chain on each peripheral plus the hub public root. During hub authentication, the hub will have to send its whole public chain, minus its root to the peripheral. The peripheral will then authenticate each node in the chain, verifying it's signed by the previous node, all the way up to the locally stored hub root. This same process can be symmetric about the two devices, i.e. the hub can authenticate the peripheral in the exact same manner. This is illustrated in the attached image.

Thanks for the info on LTK etc. I'm sure this is well documented but if you have any good primers I'd be happy to get links.

Thanks

jay

RE: Nontraditional pairing using certificates/PKI

Einar Thorsrud — Fri, 24 Jan 2020 13:14:04 GMT

Hi Jay,

Using LE Secure Connections, you can establish a secure link between two peers over BLE. An eavesdropper will not be able to obtain the key since LESC uses a Diffie–Hellman key exchange, so the link will be secure. However, without a display, keyboard, NFC or similar which you do not have, you have no standardized way of authenticating the peer, as you write. So without it, you can inadvertently establish a secure link with an attacker. If you need authentication (MITM protection), you need a non-standard system, as you write.

[quote user=""]Any reason not to go this route, or is there a better alternative for this problem?[/quote]

It depends on several factors.

Can you explain more about high this should work at a higher level? Please elaborate.
- Should any two produced devices be able to pair, or will you pair two devices during production?
- If any two devices; are the nRF devices connected to your public key infrastructure real-time somehow?
If just two devices, perhaps you could just generate a random LTK and program them with the bonding information during production? (Or provision them with each others public key for that matter, using that for your custom authentication).

[quote user=""]If x.509 certificates are used for initial authentication, should I still use the LE Secure Connections + Long Term Key (LTK) standards for the subsequent encryption and any future bonding?[/quote]

In any case, you have to use an LTK, which is the key that is used to encrypt the link. The difference between LE Secure Connections and legacy pairing (and OOB pairing) is how you obtain and exchange this key. If all you need is MITM protection (authenticity), then you could even to normal Just works LE Secure Connection pairing, and use your own method for authenticity on top of that. (Once the link is secured, communicate with the peer to see if he is the one you expected, using a challenge-response or some other mechanism).

Summing up I find it difficult to give more specific advice without knowing more details about your use case. But it is definitely possible to provide authentication via a non-standard method such as a PKI or other. Which makes more sense depends on the requirements and limitations of the specific system.

Einar