Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh
On Tue, Jan 16, 2018, Vikrant More wrote:
When I comment-out following lines as belowYes.
& when I uncomment following lines as belowYes.
DEVICE's Public key can be static or dynamic plus it can exchange overYes.
As per current implementation, we are using *dynamic Public Key*Yes.
But when I want to use static Public-Private keys for DEVICE (provisionerThe provisioner doesn't really need to know if the key is static or
public. It just needs to know which key to use for the provisioning.
What the implementation is missing right now is a way to use a static
private-public keypair instead of a dynamically generated one. We would
probably need to introduce new Kconfig option and extra code to the
current ECDH implementation (in subsys/bluetooth/host/hci_ecc.c) to read
a pre-existing public key from some persistent location instead of
generating a new key pair.
How provisioner will understand from where to received/read DEVICEI believe this is out of scope for the specification, since any OOB
channel is by definition something else than Bluetooth. In practice this
would then have to be a vendor-specific solution. There could e.g. be
hints in the advertsing data, or behind the optional URL in the
advertising data, as to what kind of OOB channel the unprovisioned node
wants to use.
If public keys get exchanged over insecure channel, then what isYou might want to read up on how Diffie-Hellman key exchange works:
You essentially acheive confidentiality for the link with the peer
you've exchanged public keys with, but only through the OOB
authentication phase will you be able to authenticate that the peer
really is who you think it is.