On Mon, Jan 15, 2018, Vikrant More wrote:
By reading this link, I understood that netKey, appKey, dveKey areThat's not completely true. Only the primary netkey and the devkey are
distributed to the node during provisioning. The other netkeys (if any)
and appkeys are distributed during the configuration phase over mesh,
and are encrypted using the keys that were distributed during
provisioning phase (primary netkey and devkey).
This encrypted *channel* is based on public-private keys. Provisioner hasYes, however I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level).
*So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE'sThe ECDH crypto is implemented in subsys/bluetooth/host/hci_ecc.c, and
it's based on TinyCrypt (which in turn is based on uECC, but let's not
get into those details :)
*And how to update that pair from default one ? *Currently all these APIs are internal, but we could (and perhaps should)
make them public. They reside in subsys/bluetooth/host/ecc.h currently.
There's e.g. bt_pub_key_get() which gives you the current public key
value (e.g. to be sent over an OOB channel), and bt_pub_key_gen() to
generate a new public-private keypair. Currently a new key pair gets
generated every time you initialize Bluetooth (by calling bt_enable).
But when we enable this,Those 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. Its subsections correspond to the
various stages that provisioning goes through. E.g. section 126.96.36.199 is
the public key exchange, and section 188.8.131.52 (called "Authentication")
the one where the Static/Output/Input OOB methods can be applied.
If Zephyr does not have own copy of public-private keys for OOB, then howAs I mentioned earlier, by making the ecc.h header file public, we could
give the app access the the public key and make it possible for it to
transfer it out-of-band to the provisioner.
One thing that is missing (since the public key APIs were not previously
available to the app) is the ability for the app to influence the
Provisioning Capabilities PDU that we send to include a flag that says
"OOB Public Key available". It's a fairly simple thing to fix though -
it'd just be one more u8_t field to the bt_mesh_prov struct.