* [PATCH BlueZ 0/1] mesh: Require Dev Key authentication @ 2019-09-15 8:14 Brian Gix 2019-09-15 8:14 ` [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions Brian Gix 0 siblings, 1 reply; 5+ messages in thread From: Brian Gix @ 2019-09-15 8:14 UTC (permalink / raw) To: linux-bluetooth; +Cc: brian.gix, inga.stotland, michal.lowas-rzechonek 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions 2019-09-15 8:14 [PATCH BlueZ 0/1] mesh: Require Dev Key authentication Brian Gix @ 2019-09-15 8:14 ` Brian Gix 2019-09-16 9:58 ` Michał Lowas-Rzechonek 0 siblings, 1 reply; 5+ messages in thread From: Brian Gix @ 2019-09-15 8:14 UTC (permalink / raw) To: linux-bluetooth; +Cc: brian.gix, inga.stotland, michal.lowas-rzechonek 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions 2019-09-15 8:14 ` [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions Brian Gix @ 2019-09-16 9:58 ` Michał Lowas-Rzechonek 2019-09-16 10:55 ` Gix, Brian 0 siblings, 1 reply; 5+ messages in thread From: Michał Lowas-Rzechonek @ 2019-09-16 9:58 UTC (permalink / raw) To: Brian Gix; +Cc: linux-bluetooth, inga.stotland 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions 2019-09-16 9:58 ` Michał Lowas-Rzechonek @ 2019-09-16 10:55 ` Gix, Brian 2019-09-16 11:08 ` Michał Lowas-Rzechonek 0 siblings, 1 reply; 5+ messages in thread From: Gix, Brian @ 2019-09-16 10:55 UTC (permalink / raw) To: Michał Lowas-Rzechonek; +Cc: linux-bluetooth, Stotland, Inga 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions 2019-09-16 10:55 ` Gix, Brian @ 2019-09-16 11:08 ` Michał Lowas-Rzechonek 0 siblings, 0 replies; 5+ messages in thread From: Michał Lowas-Rzechonek @ 2019-09-16 11:08 UTC (permalink / raw) To: Gix, Brian; +Cc: linux-bluetooth, Stotland, Inga 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-09-16 11:08 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-15 8:14 [PATCH BlueZ 0/1] mesh: Require Dev Key authentication Brian Gix 2019-09-15 8:14 ` [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions Brian Gix 2019-09-16 9:58 ` Michał Lowas-Rzechonek 2019-09-16 10:55 ` Gix, Brian 2019-09-16 11:08 ` Michał Lowas-Rzechonek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).