Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Brian Gix <brian.gix@intel.com>
To:     linux-bluetooth@vger.kernel.org
Cc:     marcel@holtmann.org, johan.hedberg@gmail.com, brian.gix@intel.com,
        inga.stotland@intel.com, michal.lowas-rzechonek@silvair.com
Subject: [PATCH BlueZ 0/1] mesh: Add D-Bus Security for sensitive data
Date:   Tue, 13 Aug 2019 18:43:56 -0700
Message-Id: <20190814014357.32453-1-brian.gix@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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