Accessing Provisioning PDUs in BLE Mesh

I am currently working on encrypting "Provisioning public key PDU" with a public key of end node that was received out of band the by provisioner before transmitting it to the provisionee who can then decrypt it with its public key. This will be in accordance to Mesh Protocol v1.1 . Where are the files in which I can access provisioning PDUs?

  • Can you please explain the part on page 591 of the Mesh Protocol?
    What I am trying to do is implement certificate-based provisioning. page 591 states that "If the public key is available using an OOB technology and the Provisioner has accessed the device's public key via an OOB technology, then the Provisioner sets the Public Key field in the Provisioning Start PDU to 1, and a new key pair shall be generated by the Provisioner, and the public key of the generated key pair shall be transmitted from the Provisioner to the Provisionee, and the public key read from the device using the appropriate OOB technology shall be used." 

    What does the last sentence mean? Public key read from the device shall be used. Does that mean it will be used to encrypt the DH public key with OOB Public key?

  • Hi,

    Utkarsh said:
    Q1. The public Key that I had created using PSA crypto APIs have an array length of 65 instead of 64. So what are the changes that I need to make before I pass it to the remote pub key set function?

    You need to pass key from element with index 1. An example how mesh generates, exports and uses public key using PSA can be found here.

    Utkarsh said:

    Q2. Also when I set the function on the provisioner with the device public key and pass the public and private keys in the bt_mesh_prov structure during the time of testing I am getting the following warnings and the provisioning fails

    <wrn> bt mesh prov: unexpected msg 0x03 != 0xff

    <wrn> bt mesh prov: unexpected msg 0x05 != 0xff

    <wrn> bt mesh pb adv : Giving up transaction 

    What I could deduce from the warning is that the end device is receiving msgs that were not expected at that time in the procisioning process. Need help regarding that

    It seems that provisioner receives public key (0x03) and confirmation (0x05) from provisionee but has already closed the link at that time. "0xff" means that provisioner does not expect any pdu's. This might indicate some error in the configuration of the provisionee. When using OOB public key, provisionee should not send it to the provisioner. You can refer to the Mesh spec - Figure 5.18: Public Key Exchange when Provisionee public key is OOB.

    Utkarsh said:
    Can you please explain the part on page 591 of the Mesh Protocol?
    What I am trying to do is implement certificate-based provisioning. page 591 states that "If the public key is available using an OOB technology and the Provisioner has accessed the device's public key via an OOB technology, then the Provisioner sets the Public Key field in the Provisioning Start PDU to 1, and a new key pair shall be generated by the Provisioner, and the public key of the generated key pair shall be transmitted from the Provisioner to the Provisionee, and the public key read from the device using the appropriate OOB technology shall be used." 

    If the provisioner gets provisionee's public key over API as shown here, it sets appropriate bit in the 'Start PDU' when starting provisioning procedure. Relevant lines in provisioner.c are these. Bit that is set allows provisionee to know that provisioner got provisionee's public key over OOB.

    Utkarsh said:
    What does the last sentence mean? Public key read from the device shall be used. Does that mean it will be used to encrypt the DH public key with OOB Public key?

    Public key is not used for encryption but for derivation. Provisioner uses provisionee's public key and its own private key to generate Diffie-Helman (DH) shared secret. Similarly, provisionee uses provisioner's public key and its own private key to generate DH shared secret. This is why the procedure of public key exchange is required.

    Best regards,
    Dejan

Related