Nontraditional pairing using certificates/PKI

[Jay]

Hi All,

I'm trying to figure out the best way to implement the security between two industrial IoT devices. We don't have a good out-of-band channel for more "traditional" BLE pairing (no user display, keypad, nfc, etc.). As a result we're considering using a public key infrastructure such as x.509 certificates to perform the initial pairing. 

• Any reason not to go this route, or is there a better alternative for this problem?
• Does anyone have any resources to facilitate this type of development that they can point me to?
• 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?

Any suggestions would be helpful.

Thanks

jay

[Einar Thorsrud]

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.

Any reason not to go this route, or is there a better alternative for this problem?

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).

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?

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

[Jay]

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

[Einar Thorsrud]

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.

Jay said:

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.

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