Hi Johan, Vinicius,
On 11/11/2011 8:55 AM, Brian Gix wrote:
On 11/10/2011 5:03 PM, Vinicius Costa Gomes wrote:
These keys are just used to encrypt the link, during SMP phase 2, they
should
not be stored nor reused. We use the same list as the LTKs to
temporarily store
them, but as soon as they are used they are removed from the list.
Signed-off-by: Vinicius Costa Gomes<vinicius.gomes@xxxxxxxxxxxxx>
---
include/net/bluetooth/hci.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 139ce2a..069768c 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -260,6 +260,7 @@ enum {
#define HCI_LK_AUTH_COMBINATION 0x05
#define HCI_LK_CHANGED_COMBINATION 0x06
/* The spec doesn't define types for SMP keys */
+#define HCI_LK_SMP_STK 0x80
#define HCI_LK_SMP_LTK 0x81
#define HCI_LK_SMP_IRK 0x82
#define HCI_LK_SMP_CSRK 0x83
At some point, we will also need to expand this list to include key
types for both Initiator and Responder (or rather, keys Locally
generated, and keys Remotely generated). Although there are 3 base types
of LE keys (4 if you count the STK), there are in fact 6 different keys
for different situations (7 if you count STK).
LTKs might be considered an exception, since most devices will only ever
be a Master or a Slave, and IRKs will often only need to be saved for
remote privacy supporting peripherals, if the local side does not use
privacy.
However, for the CSRKs, I suspect that we will need to strongly
differentiate between Locally and Remotely generated signing keys. If we
have a server with a "Signed Write Cmd" Characteristic and the remote
device has one too, we will need to sign the outbound Write Cmds with
the key the remote side distributed to us, and they will use the key
that we sent them, so we need to keep them separate.
And once you start down that path, you should at least consider the
possibility of needing to distinguish between remote and local LTKs and
IRKs as well. STKs at least do not have that problem: them are jointly
derived.
Should we add _LCL_ and _REM_ to the naming conventions, and expand the
enumeration out to 0x86?
I am including Johan in for this:
We also may want to expand or add an interface to MGMT to specify which
keys we can Generate and Accept during LE pairing. Obviously at this
point, I think this would be set to Generating No keys (if we are
Master, and Central) and accepting only the LTK (reverse that if we are
LE slaves).
Looking towards the future, the keys distributed will depend very much
on what the User space (bluez) entities are able to support.
--
Brian Gix
bgix@xxxxxxxxxxxxxx
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
