Static Authentication

[Bob J]

When static authentication is used, it is my understanding that both the provisioner and the privisionee have a static preprogrammed key. The SDK says:

"The application should respond with the static authentication data by passing it to the stack via the blahblahblah function."

I suspect that this static private key is not transmitted over the air but rather used to encrypt some the message and if the provisioner successfully decrypts some message from the provisionee authentication happens.

Is that a correct understanding or is the static preprogrammed key sent over the air unencrypted?

[tesc]

Hi,

You are correct that the static authentication value is not sent over the air. (However it would be wrong to call it a private key, as both sides are preprogrammed with the same authentication value.)

The method used for confirming the keys (the "confirmation exchange") is the same regardless of type of authentication, the difference being that with static authentication it is a pre-programmed key while with input/output authentication it is generated as needed on the output-device, displayed and then entered manually into the input-device. For the full details you can have a look at the Mesh Profile Specification, section 5.4.2 Provisioning behavior and in particular section 5.4.2.4 Authentication.

Regards,
Terje

[Bob J]

Thanks Terje,

I am reading through the Mesh Profile Spec and don't know in the diagrams used for provisioning when the particular data is encrypted or not.  I know that the beacon is transmitted in plain text. But after that it gets muddy for me. For example in the first diagram 5.12 in paragraph 5.4.2, it says in one branch:

    Start using OOB public key.

The other branch says:

    Start without OOB public key.

Does that mean that if you start without OOB public key the data is not encrypted?

When in diagram 5.12 does the data get encrypted?

I think that all data in diagram 5.13 is not encrypted. Is that correct?

In paragraph 5.2.3 it states: "If the public key was not available using an OOB technology, then the public keys are exchanged between both devices." Does that mean it exchanges public keys in plain text?

Perhaps I am missing something in the diagrams, but for me to understand and decide what is the most secure method for our product, I need to know when things are encrypted and when they are not.

Sorry if this is just obvious in the spec and I am missing it.

Warm regards

Bob

[tesc]

Hi,

I am very sorry for the delay.

From what I understand there is no encryption before the distribution of provisioning data (described in 5.4.2.5). I.e. the ECDH calculation (for encrypting the transmission of provisioning data) uses public keys that were either sent out-of-band or unencrypted over the provisioner bearer.

If you have a look at 5.4.3 Provisioning security, you will see that the public key must be transferred out-of-band in order to fill the requirements for "secure provisioning", which is the most secure way to do provisioning.

Regards,
Terje

[Bob J]

Hi Terje

Now I am the one with the delay.

I am still struggling to identify how provisioning without OOB is insecure. This is very important for us going forward with Bluetooth mesh solutions. Our customers do not want us to implement something that is deemed "insecure." So if you could further help me with this.

Here is what I understand (please correct my understanding)

After provisioning, the Mesh Network works with Symmetric key encryption.

During provisioning, the Mesh Network works with Asymmetric key encryption. (See your SDK diagram https://www.nordicsemi.com/DocLib/Content/SDK_Doc/Mesh_SDK/v3-0-0/md_doc_getting_started_provisioning where the two public keys are exchanged.)

If I understand SIG Profile Spec. 5.4.3, unless we exchange the public keys via OOB, provisioning is considered "insecure." It is my understanding that using asymmetric encryption where Alice has a public/private key pair and Bob has a public/private key pair, secure communications can take place even though they transmit their public keys in clear text (unencrypted). 

I need to clearly explain to my customers what exactly is insecure about provision if we don't use OOB key exchange and exchange our public keys unencrypted during provisioning.

I hope I have explained this well such that you can clarify my misunderstanding.