Hi Michał, I would like Marcel to weigh in on this since the security of exposing keys via D-Bus was initially a concern raised by him. Also, we may be able to leave it in the hands of the Application that owns the node. It could be as simple as the Application decides to secure the D-Bus channel (for only itself) by performing the Public Key Exchange. If the Application does *not* request a Public Key from the Daemon, and/or does not supply a Public Key during Attach/Join/Import, then the APIs work the same as they do today (albeit with extra ignored parameter(s)). An app that knows it is opperating in a secure environment can then trust the system to provide all needed security, but if for instance, some sort of hybrid D-Bus that has an insecure link in the chain, thwe App can add the Public Key exchange and encrypt/decrypt as needed. --Brian On Wed, 2019-08-14 at 09:52 +0200, Michał Lowas-Rzechonek wrote: > Hi Brian, > > On 08/13, Brian Gix wrote: > > There are various "security sensitive" pieces of data that need to be > > exchanged between Applications and the Bluetooth Mesh daemon. > > > > The following items will be encrypted before sending over D-Bus: > > > > token -- This is used by all nodes. > > > > net_keys, app_keys, dev_keys -- These will only typically be needed by > > Provisioner/Config Client nodes to extract the keys for purposes of > > Cponfiguration Database transfer. > Please don't. > > I don't see any benefit from doing so. D-Bus traffic cannot be sniffed > by an unprivileged user, and privileged user already has access to the > storage and can extract all this information from there. > > In my opinion there is little point in encrypting D-Bus traffic. Noone > else does that: > > - ConnMan sends login/password pairs over D-Bus in > https://git.kernel.org/pub/scm/network/connman/connman.git/tree/doc/vpn-agent-api.txt > - BlueZ sends pairing secrets in > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/agent-api.txt > > regards
