aboutsummaryrefslogtreecommitdiffstats
path: root/include/net/bluetooth/bluetooth.h
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2009-01-15 21:58:04 +0100
committerMarcel Holtmann <marcel@holtmann.org>2009-02-27 06:14:25 +0100
commit8c1b235594fbab9a13240a1dac12ea9fd99b6440 (patch)
treeeb137a23e0fd8199144a4c3e36902af411e44269 /include/net/bluetooth/bluetooth.h
parentc89b6e6bda4c8021195778f47567d0cc9dbfe7ec (diff)
downloadmrst-s0i3-test-8c1b235594fbab9a13240a1dac12ea9fd99b6440.tar.gz
mrst-s0i3-test-8c1b235594fbab9a13240a1dac12ea9fd99b6440.tar.xz
mrst-s0i3-test-8c1b235594fbab9a13240a1dac12ea9fd99b6440.zip
Bluetooth: Add enhanced security model for Simple Pairing
The current security model is based around the flags AUTH, ENCRYPT and SECURE. Starting with support for the Bluetooth 2.1 specification this is no longer sufficient. The different security levels are now defined as SDP, LOW, MEDIUM and SECURE. Previously it was possible to set each security independently, but this actually doesn't make a lot of sense. For Bluetooth the encryption depends on a previous successful authentication. Also you can only update your existing link key if you successfully created at least one before. And of course the update of link keys without having proper encryption in place is a security issue. The new security levels from the Bluetooth 2.1 specification are now used internally. All old settings are mapped to the new values and this way it ensures that old applications still work. The only limitation is that it is no longer possible to set authentication without also enabling encryption. No application should have done this anyway since this is actually a security issue. Without encryption the integrity of the authentication can't be guaranteed. As default for a new L2CAP or RFCOMM connection, the LOW security level is used. The only exception here are the service discovery sessions on PSM 1 where SDP level is used. To have similar security strength as with a Bluetooth 2.0 and before combination key, the MEDIUM level should be used. This is according to the Bluetooth specification. The MEDIUM level will not require any kind of man-in-the-middle (MITM) protection. Only the HIGH security level will require this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'include/net/bluetooth/bluetooth.h')
-rw-r--r--include/net/bluetooth/bluetooth.h9
1 files changed, 9 insertions, 0 deletions
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 847e9e6df08..3ad5390a4dd 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -53,6 +53,15 @@
#define SOL_SCO 17
#define SOL_RFCOMM 18
+#define BT_SECURITY 4
+struct bt_security {
+ __u8 level;
+};
+#define BT_SECURITY_SDP 0
+#define BT_SECURITY_LOW 1
+#define BT_SECURITY_MEDIUM 2
+#define BT_SECURITY_HIGH 3
+
#define BT_DEFER_SETUP 7
#define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)