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.
Methodology:
ECC Public/Private pairs, and key exchanges which are set up for each
Attach() Session, and a counting diversifier to be used as a Nonce.
The App and Daemon will each generate a single session ECC pair, and
will generate an ECDH Shared Secret, which will be used as the symetric
encription key, for AES-CCM.
For most nodes, these steps will be required only for Attaching, to
authenticate the application to the daemon while obscuring the token
from D-Bus sniffers. ECC and AES-CCM are both already natively
supported by Mesh.
Brian Gix (1):
doc: Add Pub/Private ECC shared secret to obscure sensitive data
doc/mesh-api.txt | 102 ++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 91 insertions(+), 11 deletions(-)
--
2.21.0
Certain pieces of parameter data should be considered as sensitive when
they are sent over the D-Bus, as they will be vulnerable to D-Bus
sniffers. These data parameters can reveal which are assumed to be
secrets shared between the Daemon and the owning applications. The data
that needs to be secured over D-Bus includes:
- Tokens
- Dev Keys
- Net Keys
- App Keys
ECC Pubic/Private pairs were selected for security because ECC and
ECDH shared secret handling is native to Bluetooth Mesh.
---
doc/mesh-api.txt | 102 ++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 91 insertions(+), 11 deletions(-)
diff --git a/doc/mesh-api.txt b/doc/mesh-api.txt
index 255104ab6..b6d40db4f 100644
--- a/doc/mesh-api.txt
+++ b/doc/mesh-api.txt
@@ -8,7 +8,8 @@ Interface org.bluez.mesh.Network1
Object path /org/bluez/mesh
Methods:
- void Join(object app_defined_root, array{byte}[16] uuid)
+ void Join(object app_defined_root, array{byte}[16] uuid,
+ array{byte}[64] app_pub_key, uint32 diversity)
This is the first method that an application has to call to
become a provisioned node on a mesh network. The call will
@@ -29,6 +30,15 @@ Methods:
therefore attempting to call this function using already
registered UUID results in an error.
+ The app_pub_key parameter is the public part of an ECC
+ Public/Private key pair that has been generated by the
+ application, which will be used to generate a symetric
+ encryption key to obscure the token.
+
+ The diversity parameter is used as the nonce when encrypting
+ the token. The same app_pub_key + diversity pair should never be
+ used more than once.
+
PossibleErrors:
org.bluez.mesh.Error.InvalidArguments
org.bluez.mesh.Error.AlreadyExists,
@@ -39,7 +49,8 @@ Methods:
method.
object node, array{byte, array{(uint16, dict)}} configuration
- Attach(object app_defined_root, uint64 token)
+ Attach(object app_defined_root, array{byte}[8] token,
+ array{byte}[64] app_pub_key)
This is the first method that an application must call to get
access to mesh node functionalities.
@@ -56,7 +67,15 @@ Methods:
the application when it first got provisioned/joined mesh
network, i.e. upon receiving JoinComplete() method. The daemon
uses the token to verify whether the application is authorized
- to assume the mesh node identity.
+ to assume the mesh node identity. The token is encrypted with
+ the synchronous key of the ECDH shared secret.
+
+ The app_pub_key parameter is the public part of an ECC
+ Public/Private key pair that has been generated by the
+ application, which will be used to generate a symetric
+ encryption key to obscure the token. A diversity nonce of
+ Zero is used for this call. For each Attach(), the app_pub_key
+ should be newly generated.
In case of success, the method call returns mesh node object
(see Mesh Node Hierarchy section) and current configuration
@@ -106,16 +125,23 @@ Methods:
org.bluez.mesh.Error.AlreadyExists,
org.bluez.mesh.Error.Failed
- void Leave(uint64 token)
+ void Leave(array{byte}[8] token, uint32 diversity)
This removes the configuration information about the mesh node
identified by the 64-bit token parameter. The token parameter
has been obtained as a result of successful Join() method call.
+ The diversity parameter is used as the nonce when encrypting
+ the token. The same diversity values should never be used more
+ than once and always increase, until a new App public key has
+ been generated and attached with.
+
PossibleErrors:
org.bluez.mesh.Error.InvalidArguments
- uint64 token CreateNetwork(object app_root, array{byte}[16] uuid)
+ array{byte}[8] token CreateNetwork(object app_root,
+ array{byte}[16] uuid,
+ array{byte}[64] app_pub_key, uint32 diversity)
This is the first method that an application calls to become
a Provisioner node, and a Configuration Client on a newly
@@ -136,6 +162,15 @@ Methods:
therefore attempting to call this function using already
registered UUID results in an error.
+ The app_pub_key parameter is the public part of an ECC
+ Public/Private key pair that has been generated by the
+ application, which will be used to generate a symetric
+ encryption key to obscure the token.
+
+ The diversity parameter is used as the nonce when encrypting
+ the token. The same app_pub_key + diversity pair should never be
+ used more than once.
+
The returned token must be preserved by the application in
order to authenticate itself to the mesh daemon and attach to
the network as a mesh node by calling Attach() method or
@@ -151,7 +186,8 @@ Methods:
org.bluez.mesh.Error.InvalidArguments
org.bluez.mesh.Error.AlreadyExists,
- uint64 token Import(object app_root, array{byte}[16] uuid,
+ array{byte}[8] token Import(object app_root, array{byte}[16] uuid,
+ array{byte}[64] app_pub_key, uint32 diversity,
array{byte}[16] dev_key,
array{byte}[16] net_key, uint16 net_index,
dict flags, uint32 iv_index, uint16 unicast)
@@ -168,6 +204,15 @@ Methods:
therefore attempting to call this function using already
registered UUID results in an error.
+ The app_pub_key parameter is the public part of an ECC
+ Public/Private key pair that has been generated by the
+ application, which will be used to generate a symetric
+ encryption key to obscure the token.
+
+ The diversity parameter is used as the nonce when encrypting
+ the token. The same app_pub_key + diversity pair should never be
+ used more than once.
+
The dev_key parameter is the 16-byte value of the dev key of
the imported mesh node.
@@ -208,6 +253,24 @@ Methods:
org.bluez.mesh.Error.NotSupported,
org.bluez.mesh.Error.Failed
+ array{byte}[64] daemon_pub_key GetSessionPubKey()
+
+ This method returns an ECC public key, created fresh each time
+ bluetooth-meshd restarts. The public key is used to secure all
+ privledged information from being sent in the clear over D-Bus.
+
+ The returned daemon_pub_key may be combined with a the private
+ member of a key pair to generate an ECDH Shared Secret, which is
+ used to encrypt and decrypt the following data before sending
+ over D-Bus:
+ Tokens - Private Node identifier owned by the App
+ Device keys
+ Network/Subnet keys
+ Application keys
+
+ PossibleErrors:
+ org.bluez.mesh.Error.Failed
+
Mesh Node Hierarchy
===================
Service org.bluez.mesh
@@ -487,7 +550,8 @@ Methods:
org.bluez.mesh.Error.InvalidArguments
org.bluez.mesh.Error.AlreadyExists
- void ImportSubnet(uint16 net_index, array{byte}[16] net_key)
+ void ImportSubnet(uint16 net_index, array{byte}[16] net_key,
+ uint32 diversity)
This method is used by the application to add a network subnet
key, that was originally generated by a remote Config Client.
@@ -498,6 +562,10 @@ Methods:
The net_key parameter is the 16-byte value of the net key being
imported.
+ The diversity parameter is used as the nonce when encrypting
+ the net_key. The diversity values should increase by at least 1
+ for each call to Import or Export any type of key.
+
This call affects the local bluetooth-meshd key database only.
PossibleErrors:
@@ -584,7 +652,7 @@ Methods:
org.bluez.mesh.Error.DoesNotExist
void ImportAppKey(uint16 net_index, uint16 app_index,
- array{byte}[16] app_key)
+ array{byte}[16] app_key, uint32 diversity)
This method is used by the application to add an application
key, that was originally generated by a remote Config Client.
@@ -598,6 +666,10 @@ Methods:
The app_key parameter is the 16-byte value of the key being
imported.
+ The diversity parameter is used as the nonce when encrypting
+ the app_key. The diversity values should increase by at least 1
+ for each call to Import or Export any type of key.
+
This call affects the local bluetooth-meshd key database only.
PossibleErrors:
@@ -626,7 +698,7 @@ Methods:
void CompleteAppKeyUpdate(uint16 app_index)
This method is used by the application at the completion of
- a Key Refresh Procedure. This method should be called for each
+ a Key Refresh Procedure. This method should be called for each
app key being updated during the procedure, and must be
performed prior to changing the phase of the bound net key
to phase 3. (See SetKeyPhase() method).
@@ -656,7 +728,7 @@ Methods:
org.bluez.mesh.Error.InvalidArguments
void ImportRemoteNode(uint16 primary, uint8 count,
- array{byte}[16] device_key)
+ array{byte}[16] device_key, uint32 diversity)
This method is used by the application to import a remote node
that has been provisioned by an external process.
@@ -670,6 +742,10 @@ Methods:
The device_key parameter is the access layer key that will be
will used to decrypt privledged messages from this remote node.
+ The diversity parameter is used as the nonce when encrypting
+ the device_key. The diversity values should increase by at
+ least 1 for each call to Import or Export any type of key.
+
This call affects the local bluetooth-meshd key database only.
It is an error to call this with address range overlapping
@@ -728,7 +804,7 @@ An example mesh application hierarchy may look like this:
| | - org.bluez.mesh.Element1
Methods:
- void JoinComplete(uint64 token)
+ void JoinComplete(array{byte}[8] token, uint32 diversity)
This method is called when the node provisioning initiated
by a Join() method call successfully completed.
@@ -740,6 +816,10 @@ Methods:
permanently remove the identity of the mesh node by calling
Leave() method.
+ The diversity parameter is the nonce, saved from the Join()
+ call, that is used with the ECDH shared secret to encrypt the
+ token.
+
void JoinFailed(string reason)
This method is called when the node provisioning initiated by
--
2.21.0
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
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
Hi,
I have a question concerning this change. AppKeys can also be sent using the Node1.DevKeySend() method and a Config AppKey Add
message. I assume that with a D-Bus sniffer an appKey could be extracted as well that way, will this be considered in the future as well?
Best regards
Stefan
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Brian Gix
Sent: Mittwoch, 14. August 2019 03:44
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: [PATCH BlueZ 1/1] doc: Add Pub/Private ECC shared secret to obscure sensitive data
Certain pieces of parameter data should be considered as sensitive when they are sent over the D-Bus, as they will be vulnerable to D-Bus sniffers. These data parameters can reveal which are assumed to be secrets shared between the Daemon and the owning applications. The data that needs to be secured over D-Bus includes:
- Tokens
- Dev Keys
- Net Keys
- App Keys
ECC Pubic/Private pairs were selected for security because ECC and ECDH shared secret handling is native to Bluetooth Mesh.
---
doc/mesh-api.txt | 102 ++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 91 insertions(+), 11 deletions(-)
diff --git a/doc/mesh-api.txt b/doc/mesh-api.txt index 255104ab6..b6d40db4f 100644
--- a/doc/mesh-api.txt
+++ b/doc/mesh-api.txt
@@ -8,7 +8,8 @@ Interfaceorg.bluez.mesh.Network1
Object path/org/bluez/mesh
Methods:
-void Join(object app_defined_root, array{byte}[16] uuid)
+void Join(object app_defined_root, array{byte}[16] uuid,
+array{byte}[64] app_pub_key, uint32 diversity)
This is the first method that an application has to call to
become a provisioned node on a mesh network. The call will @@ -29,6 +30,15 @@ Methods:
therefore attempting to call this function using already
registered UUID results in an error.
+The app_pub_key parameter is the public part of an ECC
+Public/Private key pair that has been generated by the
+application, which will be used to generate a symetric
+encryption key to obscure the token.
+
+The diversity parameter is used as the nonce when encrypting
+the token. The same app_pub_key + diversity pair should never be
+used more than once.
+
PossibleErrors:
org.bluez.mesh.Error.InvalidArguments
org.bluez.mesh.Error.AlreadyExists,
@@ -39,7 +49,8 @@ Methods:
method.
object node, array{byte, array{(uint16, dict)}} configuration
-Attach(object app_defined_root, uint64 token)
+Attach(object app_defined_root, array{byte}[8] token,
+array{byte}[64] app_pub_key)
This is the first method that an application must call to get
access to mesh node functionalities.
@@ -56,7 +67,15 @@ Methods:
the application when it first got provisioned/joined mesh
network, i.e. upon receiving JoinComplete() method. The daemon
uses the token to verify whether the application is authorized
-to assume the mesh node identity.
+to assume the mesh node identity. The token is encrypted with
+the synchronous key of the ECDH shared secret.
+
+The app_pub_key parameter is the public part of an ECC
+Public/Private key pair that has been generated by the
+application, which will be used to generate a symetric
+encryption key to obscure the token. A diversity nonce of
+Zero is used for this call. For each Attach(), the app_pub_key
+should be newly generated.
In case of success, the method call returns mesh node object
(see Mesh Node Hierarchy section) and current configuration @@ -106,16 +125,23 @@ Methods:
org.bluez.mesh.Error.AlreadyExists,
org.bluez.mesh.Error.Failed
-void Leave(uint64 token)
+void Leave(array{byte}[8] token, uint32 diversity)
This removes the configuration information about the mesh node
identified by the 64-bit token parameter. The token parameter
has been obtained as a result of successful Join() method call.
+The diversity parameter is used as the nonce when encrypting
+the token. The same diversity values should never be used more
+than once and always increase, until a new App public key has
+been generated and attached with.
+
PossibleErrors:
org.bluez.mesh.Error.InvalidArguments
-uint64 token CreateNetwork(object app_root, array{byte}[16] uuid)
+array{byte}[8] token CreateNetwork(object app_root,
+array{byte}[16] uuid,
+array{byte}[64] app_pub_key, uint32 diversity)
This is the first method that an application calls to become
a Provisioner node, and a Configuration Client on a newly @@ -136,6 +162,15 @@ Methods:
therefore attempting to call this function using already
registered UUID results in an error.
+The app_pub_key parameter is the public part of an ECC
+Public/Private key pair that has been generated by the
+application, which will be used to generate a symetric
+encryption key to obscure the token.
+
+The diversity parameter is used as the nonce when encrypting
+the token. The same app_pub_key + diversity pair should never be
+used more than once.
+
The returned token must be preserved by the application in
order to authenticate itself to the mesh daemon and attach to
the network as a mesh node by calling Attach() method or @@ -151,7 +186,8 @@ Methods:
org.bluez.mesh.Error.InvalidArguments
org.bluez.mesh.Error.AlreadyExists,
-uint64 token Import(object app_root, array{byte}[16] uuid,
+array{byte}[8] token Import(object app_root, array{byte}[16] uuid,
+array{byte}[64] app_pub_key, uint32 diversity,
array{byte}[16] dev_key,
array{byte}[16] net_key, uint16 net_index,
dict flags, uint32 iv_index, uint16 unicast) @@ -168,6 +204,15 @@ Methods:
therefore attempting to call this function using already
registered UUID results in an error.
+The app_pub_key parameter is the public part of an ECC
+Public/Private key pair that has been generated by the
+application, which will be used to generate a symetric
+encryption key to obscure the token.
+
+The diversity parameter is used as the nonce when encrypting
+the token. The same app_pub_key + diversity pair should never be
+used more than once.
+
The dev_key parameter is the 16-byte value of the dev key of
the imported mesh node.
@@ -208,6 +253,24 @@ Methods:
org.bluez.mesh.Error.NotSupported,
org.bluez.mesh.Error.Failed
+array{byte}[64] daemon_pub_key GetSessionPubKey()
+
+This method returns an ECC public key, created fresh each time
+bluetooth-meshd restarts. The public key is used to secure all
+privledged information from being sent in the clear over D-Bus.
+
+The returned daemon_pub_key may be combined with a the private
+member of a key pair to generate an ECDH Shared Secret, which is
+used to encrypt and decrypt the following data before sending
+over D-Bus:
+Tokens - Private Node identifier owned by the App
+Device keys
+Network/Subnet keys
+Application keys
+
+PossibleErrors:
+org.bluez.mesh.Error.Failed
+
Mesh Node Hierarchy
===================
Serviceorg.bluez.mesh
@@ -487,7 +550,8 @@ Methods:
org.bluez.mesh.Error.InvalidArguments
org.bluez.mesh.Error.AlreadyExists
-void ImportSubnet(uint16 net_index, array{byte}[16] net_key)
+void ImportSubnet(uint16 net_index, array{byte}[16] net_key,
+uint32 diversity)
This method is used by the application to add a network subnet
key, that was originally generated by a remote Config Client.
@@ -498,6 +562,10 @@ Methods:
The net_key parameter is the 16-byte value of the net key being
imported.
+The diversity parameter is used as the nonce when encrypting
+the net_key. The diversity values should increase by at least 1
+for each call to Import or Export any type of key.
+
This call affects the local bluetooth-meshd key database only.
PossibleErrors:
@@ -584,7 +652,7 @@ Methods:
org.bluez.mesh.Error.DoesNotExist
void ImportAppKey(uint16 net_index, uint16 app_index,
-array{byte}[16] app_key)
+array{byte}[16] app_key, uint32 diversity)
This method is used by the application to add an application
key, that was originally generated by a remote Config Client.
@@ -598,6 +666,10 @@ Methods:
The app_key parameter is the 16-byte value of the key being
imported.
+The diversity parameter is used as the nonce when encrypting
+the app_key. The diversity values should increase by at least 1
+for each call to Import or Export any type of key.
+
This call affects the local bluetooth-meshd key database only.
PossibleErrors:
@@ -626,7 +698,7 @@ Methods:
void CompleteAppKeyUpdate(uint16 app_index)
This method is used by the application at the completion of
-a Key Refresh Procedure. This method should be called for each
+a Key Refresh Procedure. This method should be called for each
app key being updated during the procedure, and must be
performed prior to changing the phase of the bound net key
to phase 3. (See SetKeyPhase() method).
@@ -656,7 +728,7 @@ Methods:
org.bluez.mesh.Error.InvalidArguments
void ImportRemoteNode(uint16 primary, uint8 count,
-array{byte}[16] device_key)
+array{byte}[16] device_key, uint32 diversity)
This method is used by the application to import a remote node
that has been provisioned by an external process.
@@ -670,6 +742,10 @@ Methods:
The device_key parameter is the access layer key that will be
will used to decrypt privledged messages from this remote node.
+The diversity parameter is used as the nonce when encrypting
+the device_key. The diversity values should increase by at
+least 1 for each call to Import or Export any type of key.
+
This call affects the local bluetooth-meshd key database only.
It is an error to call this with address range overlapping @@ -728,7 +804,7 @@ An example mesh application hierarchy may look like this:
| | - org.bluez.mesh.Element1
Methods:
-void JoinComplete(uint64 token)
+void JoinComplete(array{byte}[8] token, uint32 diversity)
This method is called when the node provisioning initiated
by a Join() method call successfully completed.
@@ -740,6 +816,10 @@ Methods:
permanently remove the identity of the mesh node by calling
Leave() method.
+The diversity parameter is the nonce, saved from the Join()
+call, that is used with the ECDH shared secret to encrypt the
+token.
+
void JoinFailed(string reason)
This method is called when the node provisioning initiated by
--
2.21.0
________________________________
The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.
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
Hi Brian,
On 08/14, Gix, Brian wrote:
> 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.
Ok.
> 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.
For the record - I understand the hesitation to "trust" the applications
to correctly handle security and I don't mean to dispute this. I
understand that once keys are exfiltrated from a network, all hell
might break loose.
Leaking meshd's tokens does not lead to that situation - at worst, one
could impersonate a single node.
I also agree that key export is sensitive and accesing these should
require some kind of authorization scheme.
> 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)).
This sounds complex.
Stefan raised a point about app and net keys being visible in plaintext
when application attempts to configure a node (both local and remote).
This might lead to adding encryption to mesh payloads exchanged between
the daemon and the application. Such a thing would IMO defeat the whole
idea of mesh stack implemented as a system service - it would be easier
to implement this behaviour as a library and do all the crypto on the
application side.
> 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.
As far as I know, there are only a handful of D-Bus daemon
implementations out there, and I don't think that any of them is
inherently insecure. Sure, there might be bugs and vulnerabilities, but
I am not aware of any implementation that includes an "insecure link".
Please keep in mind that D-Bus is confined within a single machine -
yes, there is a TCP transport, but virtually all setups have this turned
off, and IIRC freedeskop.org explicitly states that this feature should
not be used in a production environment.
regards
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
Hi Micha?
> On Aug 14, 2019, at 1:53 PM, "[email protected]" <[email protected]> wrote:
>
> Hi Brian,
>
>> On 08/14, Gix, Brian wrote:
>> 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.
> Ok.
>
>> 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.
> For the record - I understand the hesitation to "trust" the applications
> to correctly handle security and I don't mean to dispute this. I
> understand that once keys are exfiltrated from a network, all hell
> might break loose.
>
> Leaking meshd's tokens does not lead to that situation - at worst, one
> could impersonate a single node.
I don't think so.... If a token is leaked, and we offer *any* kind of mechanism to export keys, then any permissions that the App with legitimate access to the token has, is then conferred on *any* entity that obtains access to the token.
The only way around this is to not allow any access, by any apps, to any exportable keys.... or to secure access to the token.
>
> I also agree that key export is sensitive and accesing these should
> require some kind of authorization scheme.
>
>> 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)).
> This sounds complex.
>
> Stefan raised a point about app and net keys being visible in plaintext
> when application attempts to configure a node (both local and remote).
>
> This might lead to adding encryption to mesh payloads exchanged between
> the daemon and the application. Such a thing would IMO defeat the whole
> idea of mesh stack implemented as a system service - it would be easier
> to implement this behaviour as a library and do all the crypto on the
> application side.
>
>> 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.
> As far as I know, there are only a handful of D-Bus daemon
> implementations out there, and I don't think that any of them is
> inherently insecure. Sure, there might be bugs and vulnerabilities, but
> I am not aware of any implementation that includes an "insecure link".
>
> Please keep in mind that D-Bus is confined within a single machine -
> yes, there is a TCP transport, but virtually all setups have this turned
> off, and IIRC freedeskop.org explicitly states that this feature should
> not be used in a production environment.
>
> regards
> --
> Micha? Lowas-Rzechonek <[email protected]>
> Silvair http://silvair.com
> Jasnog?rska 44, 31-358 Krakow, POLAND
Brian,
On 08/14, Gix, Brian wrote:
> I don't think so.... If a token is leaked, and we offer *any* kind of
> mechanism to export keys, then any permissions that the App with
> legitimate access to the token has, is then conferred on *any* entity
> that obtains access to the token.
>
> The only way around this is to not allow any access, by any apps, to
> any exportable keys.... or to secure access to the token.
No, not the only way.
We could require additional authentication before attached applicatino
can access export functionality - for example, check that user running
the application belongs to a certain group.
regards
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND