Per Mesh Working group discussions, we decided that calls that require
device keys require explicit knowledge of the key being used. This
includes looped-back calls to the local Config Server, meaning that
nodes wanting to change their own states, must be granted that
permission by possession of their own key, entered into the local key
database.
We will be removing automatic device key entry nto the key database
from all methods except the Create() method.
Brian Gix (1):
mesh: Add local/remote bools to DevKey transactions
doc/mesh-api.txt | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--
2.21.0
DevKey operations require authorization on the part of the applications
making the requests. Messages to state changing Servers should use keys
from the local Key Database to demonstrate authority.
---
doc/mesh-api.txt | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/doc/mesh-api.txt b/doc/mesh-api.txt
index 9b9f4e3de..be2a337ba 100644
--- a/doc/mesh-api.txt
+++ b/doc/mesh-api.txt
@@ -245,7 +245,7 @@ Methods:
org.bluez.mesh.Error.InvalidArguments
org.bluez.mesh.Error.NotFound
- void DevKeySend(object element_path, uint16 destination,
+ void DevKeySend(object element_path, uint16 destination, bool remote,
uint16 net_index, array{byte} data)
This method is used to send a message originated by a local
@@ -259,6 +259,11 @@ Methods:
destination must be a uint16 to a unicast address, or a well
known group address.
+ The remote parameter, if true, looks up the destination address
+ in the key database to encrypt the message. If false the local
+ device key is used. If remote is true, but requested key does
+ not exist, a NotFound error will be returned.
+
The net_index parameter is the subnet index of the network on
which the message is to be sent.
@@ -782,7 +787,7 @@ Methods:
The data parameter is the incoming message.
- void DevKeyMessageReceived(uint16 source, uint16 net_index,
+ void DevKeyMessageReceived(uint16 source, bool local, uint16 net_index,
array{byte} data)
This method is called by meshd daemon when a message arrives
@@ -792,6 +797,10 @@ Methods:
The source parameter is unicast address of the remote
node-element that sent the message.
+ The local parameter if true indicates that the local device key
+ was used to decrypt the message. False indicates that the remote
+ nodes device key was used.
+
The net_index parameter indicates what subnet the message was
received on, and if a response is required, the same subnet
must be used to send the response.
--
2.21.0
Hi Brian,
On 09/15, Brian Gix wrote:
> DevKey operations require authorization on the part of the applications
> making the requests. Messages to state changing Servers should use keys
> from the local Key Database to demonstrate authority.
Alright, so if I understand this correctly:
1. If the application would like to change Config Server states on the
local node, it would need to:
- call ImportRemoteNode, passing the address of a *local* node and
the device key obtained from provisioner
- call DevKeySend to a *local* address, with remote flag set to true
- receive responses via DevKeyMessageReceived from *local* node,
with remote flag set to true
Essentially this means that talking to a local node using device
security behaves in the same manner as if the node was a remote one.
2. If the application would like to implement an external model that
uses device security, it would:
- receive DevKeyMessageReceived calls from remote nodes, with remote
flag set to false
- send responses by calling DevKeySend to a *remote* address with
remote flag set to false
This means that calling DevKeySend to a *local* address with remote flag
false would be forbidden, in order to force the application to use
ImportRemoteNode first?
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
Hi Micha?,
> On Sep 16, 2019, at 11:58 AM, Micha? Lowas-Rzechonek <[email protected]> wrote:
>
> Hi Brian,
>
>> On 09/15, Brian Gix wrote:
>> DevKey operations require authorization on the part of the applications
>> making the requests. Messages to state changing Servers should use keys
>> from the local Key Database to demonstrate authority.
>
> Alright, so if I understand this correctly:
>
> 1. If the application would like to change Config Server states on the
> local node, it would need to:
> - call ImportRemoteNode, passing the address of a *local* node and
> the device key obtained from provisioner
> - call DevKeySend to a *local* address, with remote flag set to true
> - receive responses via DevKeyMessageReceived from *local* node,
> with remote flag set to true
>
> Essentially this means that talking to a local node using device
> security behaves in the same manner as if the node was a remote one.
>
> 2. If the application would like to implement an external model that
> uses device security, it would:
> - receive DevKeyMessageReceived calls from remote nodes, with remote
> flag set to false
> - send responses by calling DevKeySend to a *remote* address with
> remote flag set to false
>
> This means that calling DevKeySend to a *local* address with remote flag
> false would be forbidden, in order to force the application to use
> ImportRemoteNode first?
I think that is all basically correct. I switched the Boolean bit-sense such that the boolean parameter is ?remote? on the send and ?local? on the receive.
And most importantly, your last point is an emphatic yes.... you will need to import your own device key to the key ring if you want to talk to your own builtin servers. The one exception will be nodes that have called ?Create()? which are generating brand new mesh networks with themselves as unicast 0001.
>
> --
> Micha? Lowas-Rzechonek <[email protected]>
> Silvair http://silvair.com
> Jasnog?rska 44, 31-358 Krakow, POLAND
Hi Brian,
On 09/16, Gix, Brian wrote:
> > 1. If the application would like to change Config Server states on the
> > local node, it would need to:
> > - call ImportRemoteNode, passing the address of a *local* node and
> > the device key obtained from provisioner
> > - call DevKeySend to a *local* address, with remote flag set to true
> > - receive responses via DevKeyMessageReceived from *local* node,
> > with remote flag set to true
> >
> > Essentially this means that talking to a local node using device
> > security behaves in the same manner as if the node was a remote one.
> >
> > 2. If the application would like to implement an external model that
> > uses device security, it would:
> > - receive DevKeyMessageReceived calls from remote nodes, with remote
> > flag set to false
> > - send responses by calling DevKeySend to a *remote* address with
> > remote flag set to false
> >
> > This means that calling DevKeySend to a *local* address with remote flag
> > false would be forbidden, in order to force the application to use
> > ImportRemoteNode first?
>
> I think that is all basically correct. I switched the Boolean
> bit-sense such that the boolean parameter is “remote” on the send and
> “local” on the receive.
>
> And most importantly, your last point is an emphatic yes.... you
> will need to import your own device key to the key ring if you want to
> talk to your own builtin servers. The one exception will be nodes
> that have called “Create()” which are generating brand new mesh
> networks with themselves as unicast 0001.
Ok, sounds good!
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND