From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:01
Hi,
This will introduce support for Exchanging Keys with remote devices.
The keys will be generated by the kernel and will be notified to
userspace so they can be stored. The management interface will
be used for this communication.
The "new key" event and the "load keys" command had to be changed, so
more information could be added to each key, for example, the long term
key has a 16bit number and a 64bit random value associated with it. But,
userpace isn't aware of the format of those keys, it just knows that they
are present or not.
Another thing that should be noted is that the link_keys list (already
present) is used to store these keys, including the Short Term Key, as
it makes the handling of this type of key more transparent.
The related userspace changes should appear a little after this series.
Cheers,
--
Anderson Lizardo (1):
Bluetooth: Add support for random destination address
Vinicius Costa Gomes (12):
Bluetooth: Add support for SMP phase 3 (key distribution)
Bluetooth: Fix sending wrong IO Capabilities value
Bluetooth: Add new structures for supporting SM key distribution
Bluetooth: Add functions to manipulate the link key list for SMP
Bluetooth: Reject an encryption request when the key isn't found
Bluetooth: Add support for providing parameters to LE Start
Encryption
Bluetooth: Fix SM pairing parameters negotiation
Bluetooth: Add support for storing the LTK
Bluetooth: Use the link key list to temporarily store the STK
Bluetooth: Use the stored LTK for restabilishing security
Bluetooth: Remove unused field in hci_conn
Bluetooth: Add support for communicating keys with userspace
include/net/bluetooth/hci.h | 4 +
include/net/bluetooth/hci_core.h | 25 ++++-
include/net/bluetooth/mgmt.h | 2 +
include/net/bluetooth/smp.h | 1 +
net/bluetooth/hci_conn.c | 5 +-
net/bluetooth/hci_core.c | 81 ++++++++++++++
net/bluetooth/hci_event.c | 18 +++-
net/bluetooth/l2cap_core.c | 1 +
net/bluetooth/mgmt.c | 60 ++++++++---
net/bluetooth/smp.c | 214 ++++++++++++++++++++++++++++++++++----
10 files changed, 368 insertions(+), 43 deletions(-)
--
1.7.5.4
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:02
This adds support for generating and distributing all the keys
specified in the third phase of SMP.
This will make possible to re-establish secure connections, resolve
private addresses and sign commands.
For now, the values generated are random.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
include/net/bluetooth/smp.h | 1 +
net/bluetooth/l2cap_core.c | 1 +
net/bluetooth/smp.c | 114 ++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 114 insertions(+), 2 deletions(-)
@@ -462,6 +462,26 @@ int smp_conn_security(struct l2cap_conn *conn, __u8 sec_level)return0;}+staticintsmp_cmd_encrypt_info(structl2cap_conn*conn,structsk_buff*skb)+{+BT_DBG("conn %p",conn);+/* FIXME: store the ltk */+return0;+}++staticintsmp_cmd_master_ident(structl2cap_conn*conn,structsk_buff*skb)+{+structsmp_cmd_pairing*paircmd=(void*)&conn->prsp[1];+u8keydist=paircmd->init_key_dist;++BT_DBG("keydist 0x%x",keydist);+/* FIXME: store ediv and rand */++smp_distribute_keys(conn,1);++return0;+}+intsmp_sig_channel(structl2cap_conn*conn,structsk_buff*skb){__u8code=skb->data[0];
@@ -503,10 +523,20 @@ int smp_sig_channel(struct l2cap_conn *conn, struct sk_buff *skb)break;caseSMP_CMD_ENCRYPT_INFO:+reason=smp_cmd_encrypt_info(conn,skb);+break;+caseSMP_CMD_MASTER_IDENT:+reason=smp_cmd_master_ident(conn,skb);+break;+caseSMP_CMD_IDENT_INFO:caseSMP_CMD_IDENT_ADDR_INFO:caseSMP_CMD_SIGN_INFO:+/* Just ignored */+reason=0;+break;+default:BT_DBG("Unknown command code 0x%2.2x",code);
@@ -523,3 +553,83 @@ done:kfree_skb(skb);returnerr;}++intsmp_distribute_keys(structl2cap_conn*conn,__u8force)+{+structsmp_cmd_pairing*req,*rsp;+__u8*keydist;++BT_DBG("conn %p force %d",conn,force);++if(IS_ERR(conn->hcon->hdev->tfm))+returnPTR_ERR(conn->hcon->hdev->tfm);++rsp=(void*)&conn->prsp[1];++/* The responder sends its keys first */+if(!force&&conn->hcon->out&&(rsp->resp_key_dist&0x07))+return0;++req=(void*)&conn->preq[1];++if(conn->hcon->out){+keydist=&rsp->init_key_dist;+*keydist&=req->init_key_dist;+}else{+keydist=&rsp->resp_key_dist;+*keydist&=req->resp_key_dist;+}+++BT_DBG("keydist 0x%x",*keydist);++if(*keydist&SMP_DIST_ENC_KEY){+structsmp_cmd_encrypt_infoenc;+structsmp_cmd_master_identident;+__le16ediv;++get_random_bytes(enc.ltk,sizeof(enc.ltk));+get_random_bytes(&ediv,sizeof(ediv));+get_random_bytes(ident.rand,sizeof(ident.rand));++smp_send_cmd(conn,SMP_CMD_ENCRYPT_INFO,sizeof(enc),&enc);++ident.ediv=cpu_to_le16(ediv);++smp_send_cmd(conn,SMP_CMD_MASTER_IDENT,sizeof(ident),&ident);++*keydist&=~SMP_DIST_ENC_KEY;+}++if(*keydist&SMP_DIST_ID_KEY){+structsmp_cmd_ident_addr_infoaddrinfo;+structsmp_cmd_ident_infoidinfo;++/* Send a dummy key */+get_random_bytes(idinfo.irk,sizeof(idinfo.irk));++smp_send_cmd(conn,SMP_CMD_IDENT_INFO,sizeof(idinfo),&idinfo);++/* Just public address */+memset(&addrinfo,0,sizeof(addrinfo));+bacpy(&addrinfo.bdaddr,conn->src);++smp_send_cmd(conn,SMP_CMD_IDENT_ADDR_INFO,sizeof(addrinfo),+&addrinfo);++*keydist&=~SMP_DIST_ID_KEY;+}++if(*keydist&SMP_DIST_SIGN){+structsmp_cmd_sign_infosign;++/* Send a dummy key */+get_random_bytes(sign.csrk,sizeof(sign.csrk));++smp_send_cmd(conn,SMP_CMD_SIGN_INFO,sizeof(sign),&sign);++*keydist&=~SMP_DIST_SIGN;+}++return0;+}
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:03
We should send the IO Capabilities set by userspace, using the
management interface, instead of a fixed value.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/smp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Date: 2011-06-08 08:20:41
Hi Vinicius,
On Wed, Jun 8, 2011 at 7:50 AM, Vinicius Costa Gomes
[off-list ref] wrote:
quoted hunk
We should send the IO Capabilities set by userspace, using the
management interface, instead of a fixed value.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/smp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Does this fix something that is not upstream yet? If not then we
should be fixing it in place whenever possible.
--
Luiz Augusto von Dentz
Computer Engineer
From: Vinicius Costa Gomes <hidden> Date: 2011-06-08 16:30:35
Hi Luiz,
On 17:20 Wed 08 Jun, Luiz Augusto von Dentz wrote:
Hi Vinicius,
On Wed, Jun 8, 2011 at 7:50 AM, Vinicius Costa Gomes
[off-list ref] wrote:
quoted
We should send the IO Capabilities set by userspace, using the
management interface, instead of a fixed value.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/smp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:04
We need these changes because SMP keys may have more information
associated with them, for example, in the LTK case, it has an
encrypted diversifier (ediv) and a random number (rand).
Signed-off-by: Vinicius Costa Gomes <redacted>
---
include/net/bluetooth/hci.h | 4 ++++
include/net/bluetooth/hci_core.h | 16 ++++++++++++++++
include/net/bluetooth/mgmt.h | 2 ++
3 files changed, 22 insertions(+), 0 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:05
As the LTK (the new type of key being handled now) has more data
associated with it, we need to store this extra data and retrieve
the keys based on that data.
Methods for searching for a key and for adding a new LTK are
introduced here.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
include/net/bluetooth/hci_core.h | 5 ++
net/bluetooth/hci_core.c | 81 ++++++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+), 0 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:06
Now that we have methods to finding keys by its parameters we can
reject an encryption request if the key isn't found.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/hci_event.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:07
With LTK support we need to be able to provide LE Start Encryption
with EDIV (Encrypted Diversifier) and Rand (just an 64 bit random
number).
Signed-off-by: Vinicius Costa Gomes <redacted>
---
include/net/bluetooth/hci_core.h | 3 ++-
net/bluetooth/hci_conn.c | 5 ++++-
net/bluetooth/smp.c | 7 ++++++-
3 files changed, 12 insertions(+), 3 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:08
Before implementing SM key distribution, the pairing features
exchange must be better negotiated, taking into account some
features of the host and connection requirements.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/smp.c | 42 ++++++++++++++++++++++++++++++++----------
1 files changed, 32 insertions(+), 10 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:09
Now when the LTK is received from the remote or generated it is stored,
so it can later be used.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/smp.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
@@ -491,18 +491,23 @@ int smp_conn_security(struct l2cap_conn *conn, __u8 sec_level)staticintsmp_cmd_encrypt_info(structl2cap_conn*conn,structsk_buff*skb){-BT_DBG("conn %p",conn);-/* FIXME: store the ltk */+structsmp_cmd_encrypt_info*rp=(void*)skb->data;++skb_pull(skb,sizeof(*rp));++memcpy(conn->tk,rp->ltk,sizeof(conn->tk));+return0;}staticintsmp_cmd_master_ident(structl2cap_conn*conn,structsk_buff*skb){-structsmp_cmd_pairing*paircmd=(void*)&conn->prsp[1];-u8keydist=paircmd->init_key_dist;+structsmp_cmd_master_ident*rp=(void*)skb->data;++skb_pull(skb,sizeof(*rp));-BT_DBG("keydist 0x%x",keydist);-/* FIXME: store ediv and rand */+hci_add_ltk(conn->hcon->hdev,1,conn->src,rp->ediv,+rp->rand,conn->tk);smp_distribute_keys(conn,1);
@@ -621,6 +626,9 @@ int smp_distribute_keys(struct l2cap_conn *conn, __u8 force)smp_send_cmd(conn,SMP_CMD_ENCRYPT_INFO,sizeof(enc),&enc);+hci_add_ltk(conn->hcon->hdev,1,conn->dst,ediv,+ident.rand,enc.ltk);+ident.ediv=cpu_to_le16(ediv);smp_send_cmd(conn,SMP_CMD_MASTER_IDENT,sizeof(ident),&ident);
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:10
With this we can use only one place to store all keys, without
need to use a field in the connection structure for this
purpose.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/smp.c | 23 +++++++++++++++--------
1 files changed, 15 insertions(+), 8 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:11
Now that it's possible that the exchanged key is present in
the link key list, we may be able to estabilish security with
an already existing key, without need to perform any SMP
procedure.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/smp.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:13
As the key format has changed to something that has a dynamic size,
the way that keys are received and sent must be changed.
The structure fields order is changed to make the parsing of the
information received from the Management Interface easier.
Signed-off-by: Vinicius Costa Gomes <redacted>
---
net/bluetooth/mgmt.c | 60 +++++++++++++++++++++++++++++++++++++------------
1 files changed, 45 insertions(+), 15 deletions(-)
From: Vinicius Costa Gomes <hidden> Date: 2011-06-07 22:50:14
From: Anderson Lizardo <redacted>
For source address, only public address type is supported for now.
Signed-off-by: Anderson Lizardo <redacted>
---
net/bluetooth/smp.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Date: 2011-06-09 13:02:36
Hi Vinicius,
On Wed, Jun 8, 2011 at 7:50 AM, Vinicius Costa Gomes
[off-list ref] wrote:
Hi,
This will introduce support for Exchanging Keys with remote devices.
The keys will be generated by the kernel and will be notified to
userspace so they can be stored. The management interface will
be used for this communication.
The "new key" event and the "load keys" command had to be changed, so
more information could be added to each key, for example, the long term
key has a 16bit number and a 64bit random value associated with it. But,
userpace isn't aware of the format of those keys, it just knows that they
are present or not.
Another thing that should be noted is that the link_keys list (already
present) is used to store these keys, including the Short Term Key, as
it makes the handling of this type of key more transparent.
The related userspace changes should appear a little after this series.
Cheers,
--
Anderson Lizardo (1):
Bluetooth: Add support for random destination address
Vinicius Costa Gomes (12):
Bluetooth: Add support for SMP phase 3 (key distribution)
Bluetooth: Fix sending wrong IO Capabilities value
Bluetooth: Add new structures for supporting SM key distribution
Bluetooth: Add functions to manipulate the link key list for SMP
Bluetooth: Reject an encryption request when the key isn't found
Bluetooth: Add support for providing parameters to LE Start
Encryption
Bluetooth: Fix SM pairing parameters negotiation
Bluetooth: Add support for storing the LTK
Bluetooth: Use the link key list to temporarily store the STK
Bluetooth: Use the stored LTK for restabilishing security
Bluetooth: Remove unused field in hci_conn
Bluetooth: Add support for communicating keys with userspace
include/net/bluetooth/hci.h | 4 +
include/net/bluetooth/hci_core.h | 25 ++++-
include/net/bluetooth/mgmt.h | 2 +
include/net/bluetooth/smp.h | 1 +
net/bluetooth/hci_conn.c | 5 +-
net/bluetooth/hci_core.c | 81 ++++++++++++++
net/bluetooth/hci_event.c | 18 +++-
net/bluetooth/l2cap_core.c | 1 +
net/bluetooth/mgmt.c | 60 ++++++++---
net/bluetooth/smp.c | 214 ++++++++++++++++++++++++++++++++++----
10 files changed, 368 insertions(+), 43 deletions(-)
This patches seems to be working fine, tried with pts and some other
stacks without problem, the only inconvenients for testing are the
hardcoded io capabilitity, hardcoded distribution keys (it seems we
distribute only LTK) and not being able to remove keys other than
remove the adapter (didn't try reset).
--
Luiz Augusto von Dentz
Computer Engineer
From: Anderson Lizardo <hidden> Date: 2011-06-09 13:09:49
Hi Luiz,
On Thu, Jun 9, 2011 at 9:02 AM, Luiz Augusto von Dentz
[off-list ref] wrote:
This patches seems to be working fine, tried with pts and some other
stacks without problem, the only inconvenients for testing are the
hardcoded io capabilitity, hardcoded distribution keys (it seems we
distribute only LTK) and not being able to remove keys other than
remove the adapter (didn't try reset).
About the "not being able to remove keys" part, there is some proposal
(original code is from Johan) to a "mgmt tool" that could be used to
remove keys. Also note that if the remote reports pairing error due to
"missing key or PIN", the bluez side will forget the keys and issue a
fresh pairing.
Not sure what you meant about "hardcoded distribution keys". IIRC I've
seen at least master and identity information distributed as well (but
Vinicius can definitely confirm or deny that).
HTH,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil