OOB Provisioning and OOB Authentication

[Bob J]

I am trying to understand the provisioning process as defined in the Bluetooth Mesh Profile v1.01 specification. In particular, I don't understand the following paragraph 5

After the provisioning bearer is established, the Provisioner establishes a shared secret with the device using an Elliptic Curve Diffie-Hellman (ECDH) protocol. It then authenticates the device using OOB information that is specific to that device. Such OOB information may include a public key of the device, a long secret, the requirement to input a value into the device, or the requirement to output a value on that device. Such OOB information also enables the authentication of that device.

I am confused about the process chronology.  The spec states that 

1. The provisioner establishes a shared secret
2. It then authenticates the device using OOB information.
3. Such OOB information also enables the authentication of that device

This seems self-referential and it confuses me. The OOB information seems to both be used to authenticate and enable authentication. I have no idea what "enables the authentication" means. Is that statement redundant?

This also seems to contradict Figure 5.12. Earlier posts in this forum indicated that a static authentication would be considered OOB but this figure seems to make it an either or.

Where this is heading is the spec statement that says in so many words "Provisioning is not secure unless OOB is used." I understand that to mean that the device would be subject to MITM attacks unless OOB is used. Figure 5.12 seems to lump static and no OOB together. If you use some form of static authentication (eg provisioner has a list of MAC addresses that it will accept?

Perhaps, more simply stated my question is:

Can my devices generate their OOB information from the MAC and a private algorithm and this be used for both initial key exchange and authentication? Is that secure? and Is it supported in your SDK?

OR

What is a secure way to provision without using OOB Output, OOB Input, or OOB NFC? I cannot seem to find diagrams in the spec that lay this out.

Thanks for your patience with me.

[Joakim Jakobsen]

Hi.

I have no idea what "enables the authentication" means. Is that statement redundant?

It wouldn't say redundant, but the two statements might be a little repetitive.

___________________________________________________

The OOB methods are steps that can happen after the public key exchange. I really recommend you to read through section "5.4.2 Provisioning behavior" in the Mesh Profile specification. The subsections correspond to the various stages that provisioning goes through. Section 5.4.2.3 is the public key exchange, and section 5.4.2.4 (called "Authentication") is the one where the Static/Output/Input OOB methods can be applied.

Can my devices generate their OOB information from the MAC and a private algorithm and this be used for both initial key exchange and authentication?

 I don't see why that shouldn't be possible, but i don't think this is something that is supported in our SDK.

I think using a 128-bit randomly generated Static OOB value should be considered as a secure way to provision your device.

Best regards.