I am working on 802.11i security implementation and I am stuck quite at the beginning. My work is based on existing framework which broadcasts open WiFi network and devices are successfully able to connect.
In order to inform STAs of access restrictions, I added RSN (Robust Security Network) element into Tagged parameters of Beacons and Probe Response frames. I defined both suites (Group and Pairwise) with 802.11 standardized values setting to AES and AuthKey setting to both PSK and 802.1X.
After this frame is sent, no Authentication Request is generated from STAs and I got response on all of them (Win7, Android and iOS) that device cannot connect. I compared Wireshark traces with multiple connection establishments, and cannot figure out what doesn't add up. Only thing I modified is addition of RSN and this RSN is absolutely the same as in other production connection attempts.
What I thought is that either device rejects frame because of improper implementation/format, or it doesn't support offered security mechanisms. But then - removing RSN field (making network open) allows STAs to proceed with Authentication Req; and looking into Probe Responses from real APs, they have the exact same structure and contents of RSN.
And other interesting behavior is that Apple device (iPad) doesn't even recognize network as secured with RSN field implemented while both Win7 and Android do.
Any ideas what am I missing or misunderstanding?
Screenshots: First is working real communication, second is my implemented modification.
Related
first of all: What i am trying to do is only for private interest.
I'd like to connect a AT-09/HM-10 BLE-Module with Firmware 6.01 to another device which provides also a BLE Module, which it is not based on the CC254X-Chip,
I am able to communicate with this Device using my Laptop with integrated Bluetooth, Linux and the bluepy-helper. I am also able to make a connection using the HM10 through a USB-RS232-Module and "Hterm", but after that quite Stuck in my progress.
By "reverse-engineering" the Android-Application for controlling this particular device i found a set of Commands, stored as Strings in Hex-Format. The Java-Application itself sends out the particular Command combined with a CRC16-Modbus-Value in addition with a Request (whatever it is), to a particular Service and Characteristic UUID.
I also have a Wireshark-Protocol pulled from my Android-Phone while the application was connected to the particular device, but i am unable to find the commands extracted from the .apk in this protocol.
This is where i get stuck. After making a connection and sending out the Command+CRC16-Value i get no response at all, so i am thinking that my intentions are wrong. I am also not quite sure how the HM-10-Firmware handles / maps the Service and Char-UUIDs from the destination device.
Are there probably any special AT-Commands which would fit my need?
I am absolutely not into the technical depths of Bluetooth and its communication layer at all. The only thing i know is that the HM-10 connects to a selected BLE-Device and after that it provides a Serial I/O and data flows between the endpoints.
I have no clue how and if it can handle Data flow to certain Service/Char UUIDs from the destination endpoint, althrough it seems to have built-in the GATT , l2cap-Services and so on. Surely it handles all the neccessary communication by itself, but i don´t know where i get access to the "front-end" at all.
Best regards !
We are currently working on an application on linux (a.o. RasPi running latest Debian Jessie) that connects to a BLE device (developed by us). This tool has evolved from cherry-picking files from the bluez (5.46) stack and adding an application layer on top. This all works quite nicely, except for the fact that connecting is incredibly slow. From the output of our tool, I understand that a truckload of messages need to be exchanged to communicate GATT services and characteristics, and each of those costs one connection interval of time. Since it is a low power device, we want the connection interval to be relatively high, and thus the high delay.
When connecting with Android BLE Scanner, I see (on the device side) that BLE Scanner manipulates the connection interval to a low value, gets all the requested data, and then sets the connection interval back to its original value. Note, btw, that neither BLE Scanner nor our Bluez-derived application take the preferred connection parameters into account.
Now I want to have our application do the same: set the connection interval to 8ms, get all info about characteristics and services, and set the connection interval back. In the Bluez stack I even find a nice function in the HCI layer for this: hci_le_conn_update.
But now the challenge: the rest of the application is built on top of the GATT functionality and even though the BLE specification defines a hierarchy between those two (with some layers in between), in code they seem absolutely independent of each other.
There are two parameters to the hci_le_conn_update function that are HCI specific: 'dd' (file descriptor to device) and 'handle' (some value that identifies the connection). The hcitool tells me that when I create a connection, the first handle is 64, so I tried with that value. For 'dd' I used hci_dev_open to get a file descriptor for the device. This worked. Sort of.
As I said before, the min/max values are not entirely taking into account. So when I set it to 6/10, I get 11 and when I set it to 6/50, I get 60. This is a bit too undeterministic for my taste, and I would prefer a function that directly changes the connection interval instead of giving a range that is mostly ignored anyway. Also the fact that I have to use a hardcoded magic number 64 gives me a bad itch. I can actually control the connection interval on the embedded device's side, but I want the control at the side of the client application.
The goal is to update the connection interval in a Bluez-GATT-based application. Within certain limits, I do not mind that much how I get there. Any suggestions?
In the official dbus API, there is no method to change connection parameters. (See https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt and https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt). The key is therefore to send the Connection Parameter Update Request from the peripheral side. You can of course experiment with sending a raw hci command but that is a bit "hacky" and has no guarantees to not mess up the BlueZ daemon.
If you would like to discuss the features of BlueZ such as an connection parameter update request api, you should do that on the BlueZ mailing list (http://www.bluez.org/contact/) rather than here.
We are testing Bluetooth in WEC2013 with a USB based dongle from generic vendor on iMx6 platform. We are using the default HCI Transport layer provided with WEC2013 BSP.
BT is turned on and able to scan all the nearby devices.
We have enabled following set of sysgen variables and registry entry.
Sysgen Variables:
SYSGEN_BTH (Bluetooth stack with universal loadable driver)
SYSGEN_BTH_BTHUTIL (Bluetooth Profile Management APIs)
SYSGEN_BTH_HID_KEYBOARD (Bluetooth HID - Keyboard)
SYSGEN_BTH_HID_MOUSE (Bluetooth HID - Mouse)
SYSGEN_BTH_AG (Bluetooth HS/HF and Audio gateway service)
SYSGEN_BTH_SETTINGS (Bluetooth settings UI)
SYSGEN_OBEX_CLIENT (Obex client)
SYSGEN_OBEX_SERVER (Obex server)
SYSGEN_OBEX_FILEBROWSER (OBEX file browser)
SYSGEN_OBEX_INBOX (OBEX Inbox)
SYSGEN_FTPD (FTP server)
SYSGEN_BTH_BTHSSVC(Support Secure Simple Pairing)
Registry entry:
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\224_1_1\Default\Bluetooth_USB_Driver]
"DLL"="bthusb.dll"
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\224_1_1\Bluetooth_USB_Driver]
"DLL"="bthusb.dll"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\Transports\PnP\{B3DD867A-1E6E-4215-8AA7-EAC1DFC46548}]
"flags"=dword:80000000
"driver"="bthusb.dll"
"resetdelay"=dword:0
"PacketSize"=dword:200
"BlockSize"=dword:5
[HKEY_LOCAL_MACHINE\ControlPanel\Bluetooth]
"PinAttemptInterval"=dword:200000
"PinEntries"=multi_sz:"0000","8888"
We observed different scenario's in pairing to a device.
Connecting to mobile from board(imx6+usb dongle running with WEC2013)
Here pairing is success when pair is initiated through bthsettings UI. It will trigger the 6-digit automated passkey on both the sides.
Connecting from mobile to board without opening bthsettings UI.
Here pairing is success once. When the UI is not open (BT is ON in background), pairing is initiated from mobile, both will be paired using automated
6-digit passkey method. But this will internally invoke bthsettings UI, so next time when we give pairing from mobile, mobile side will ask for manual
key insertion. As soon as the key is entered on mobile and pair is pressed, pairing rejected notification will be observed on mobile terminal.
So pairing is failed in this case.
Connecting from mobile to board when bthsettings is opened.
Here pairing is failed. When pair is initiated from mobile, manual key insertion UI will be invoked and when key is inserted and pair is pressed,
pairing rejected notification will be displayed on mobile terminal and pairing is failed.
In these failed senarios, the upper layer is responding with "Pin code request negative reply command" for "Pin code request event" from chip.
We need input on this pairing process. Why this automated key and manual key generation methods are invoked based on whether UI is open or never opened? And why manual key case is failing?
Are we missing any registry entry or stack feature ?
It all got to do with SSP(Secured Simple Pairing), which decides the pairing authentication model. This is affected in WEC8(2013) through the changes under bthsettings.
Under WEC8 they disable SSP(via function EnbaleSSP()) whenever a connection is initiated from external device and enable back SSP when conenction is initiated internally. Though this is the logic, I'm not aware of why this is introduced(and is it a bug, that'll be fixed in upcoming updates as they initially did for NDIS 5 wireless driver connection).
And as a workaround to this, disable EnableSSP().
Also SYSGEN_BTH_BTHSSVC is implicitly needed by SYSGEN_BTH_SETTINGS component, and the link is broken under WEC8.
Microsoft has provided the fix in April 2015 update. Details available here.
Currently we are setting up a Bluetooth LE device specification and we are running against the following:
The client doesn't want to pair the device via the settings menu. There is a mobile app which should connect to the peripheral.
Now the following, this is the problem:
When connecting, how do we secure our characteristics? We were thinking about prefixing a write request, but what about read requests?
We don't want everybody to see the not so sensitive data. Since it's not sensitive we don't need high security but we still need to secure it some way just in case.
Does anybody know how to do this? How to secure a characteristic?
Thanks in advance,
You could implement a challenge-response system on connection - when you connect to the peripheral you read a value from a characteristic which is randomised by the peripheral. This value has to be hashed in some way using a shared-secret and then written back to the characteristic. The peripheral then verifies the hashed value. If it matches then it populates the other characteristics and accepts write requests.
Once the central disconnects from the peripheral it ignores write requests and zeros its read characteristics until the next connection/hash handshake.
You must add Security Mode 1 Level 3 to your Services. Then, all the Service's characteristics will be protected.
I understand many of the fine details of NAT hole punching, ICE, and SIP VOIP calls. I've answered quite a few questions on SO on these topics. Now I have a question.
I am trying to understand the need for the RE-INVITE message that is documented for SIP+ICE after the call is already established.
Assume a topology of VOIP devices that signal over SIP and using ICE (with STUN/TURN) for establishing media connectivity. After the ICE connectivity checks are performed, both endpoints should have ascertained the best address candidate pairings (IP,port) and should be ready to stream media in both directions.
But my experience with SIP and plenty of documentation suggests that after the callee sends a 200 OK message to indicate he's in the answered state, the caller is to expected send a RE-INVITE with an SDP containing the specific address candidate selected by the connectivity checks.
Some links that describe the RE-INVITE with ICE are here and here (step 8). Rosenberg's tutorial (page 30) discusses that the RE-INVITE "ensures that middleboxes have the correct media address". I'm not sure why that's important.
Upon receiving a RE-INVITE, is the callee expected to reconfigure his ICE stack to switch sockets or addresses based on the new SDP received? Or is the RE-INVITE just a protocol formality to formally acknowledge the call has been established? If the RE-INVITE step was skipped and both sides started streaming media, what could go wrong?
The reason why I ask is because I am exploring using ICE over a signaling service that is not SIP. I'm trying to figure out if the RE-INVITE needs to be emulated.
One example of middlebox, which may be interested in the result of the ICE negotiation is a bandwidth manager.
Imagine an enterprise deployment, with endpoints inside the corporate firewall and others roaming around on the Internet, or behind private home firewalls. The deployment also includes a publicly accessible TURN server. Then let's imagine an endpoint inside the corporate firewall making a call. If the destination happens to be reachable on the same network, the call will go host to host and the TURN server will not be used (i.e. bindings will be de-allocated). This is a local network, and no bandwidth limitation needs to be imposed. On the other hand, if the call goes out to a roaming endpoint, then the TURN server will get involved, and data will flow through the corporate firewall, through what probably is a limited bandwidth uplink. We can very well imagine some policy that would want to limit the call's bandwidth. One way of doing it, is for the bandwidth manager to remain in the signaling path (using SIP record-routes) and look into the SDP of any INVITE going through, re-writing bandwidth values depending on media addresses.
I believe the general intention was, that legacy equipment of that type, which is not ICE aware, should keep working in a mixed environment introducing ICE endpoints. To keep this backwards compatibility, ICE should only introduce new processing (STUN checks, etc), but from the point of view of non-ICE-aware elements, it should not remove any existing rules (re-INVITEs are still needed to change the destination of a media stream).
In Rosenberg's tutorial I believe the re-INVITE is sent because the sockets chosen by ICE are different from those in the media and connection (m/c-lines) lines of the original SDP AND in order for any network elements that are in between the two user agents to be informed of the actual sockets that will be used RTP a re-INVITE is sent with the ICE selected socket(s) in the media and connection lines of the SDP.
If the ICE selected sockets were the same as the ones in the original INVITE request's SDP m/c lines then there would be no need for the re-INVITE request. Or if you know there are no "middleboxes" that need to be informed of the changes to the RTP sockets then there would also be no need to send the re-INVITE.