[PATCH BlueZ 0/1] mesh: Require Dev Key authentication

[PATCH BlueZ 0/1] mesh: Require Dev Key authentication

[Brian Gix]

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

[PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions

[Brian Gix]

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

Re: [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions

[Michał Lowas-Rzechonek]

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 <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

Re: [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions

[Gix, Brian]

Hi Michał, 

> On Sep 16, 2019, at 11:58 AM, Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com> 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 <michal.lowas-rzechonek@silvair.com>
> Silvair http://silvair.com
> Jasnogórska 44, 31-358 Krakow, POLAND

Re: [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions

[Michał Lowas-Rzechonek]

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 <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND