4.71 KB, text/plain
14.57 KB, text/plain
4.16 KB, patch
|Details | Diff | Splinter Review|
Encryption should be used for bluetooth socket to protect the confidentiality of messages. However, when I try to create an encrypted socket by calling BluetoothService::GetSocketViaService, it fails and returns "EACCES" (errno: 13, Permission denied).
When we set both mAuth and mEncrypt to true, resulting in enabling RFCOMM_LM_SECURE (Please see BluetoothUnixSocketConnector.cpp, L91). This triggers the pairing process again to get new link key and produces an error: Pairing Not Allowed.
Assignee: nobody → gyeh
Here's the hcidump after removing RFCOMM_LM_SECURE. Pairing process won't be triggered here and can successfully create an encrypted and authorized socket. Can we remove RFCOMM_LM_SECURE here? Or is there a way to fix this?
Comment on attachment 676103 [details] [diff] [review] Patch 1(v1) - Remove RFCOMM_LM_SECURE and set encrypted to true Ok, looks good. Only thing I wonder about is if we want some key to decrypt things for debugging purposes. Probably not, just something to consider. :)
Attachment #676103 - Flags: feedback?(kyle) → feedback+
So I'm noticing other projects where RFCOMM_LM_SECURE is commented out too. Any idea what this is doing, Eric?
Encrypted sockets are needed for certification.
blocking-basecamp: ? → +
Priority: -- → P1
Attachment #676103 - Flags: review?(echou)
Comment on attachment 676103 [details] [diff] [review] Patch 1(v1) - Remove RFCOMM_LM_SECURE and set encrypted to true Review of attachment 676103 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. I agree that we need to make encrypted LM connections. I think it's o.k to remove RFCOMM_LM_SECURE/RFCOMM_LM_SECURE from BluetoothUnixSocketConnector::SetUp(). When *_LM_SECURE flag is set, it means we are going to create a connection with the highest security level(level 3) to prevent MITM(Man-In-The-Middle) attack. However, it would become very easy to get "Pairing not allowed" error when we try to pair. Although I'm still looking for the reason, it will still be better to have connections encrypted. For more information, please see section "Security mode 4" in GAP(Generic Access Profile) spec.
Attachment #676103 - Flags: review?(echou) → review+
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.