Bluetooth changes in Windows 7

A number of changes are apparent in Windows support for Bluetooth in Windows 7 — some of which were added to Vista in the “Windows Vista Feature Pack for Wireless” see KB942567[i].

· The first visible change is that Bluetooth devices are shown in the “Device and Printers” control panel. New devices can also be added from there.

· Even better, the “Select Device” dialog — as used by “Bluetooth File Transfer Wizard” etc — is now much more useable. In XP it is completely empty until a complete discovery process has been run i.e. >10seconds. In Windows 7 the remembered devices are shown immediately and any discovered devices appear one-by-one as they are discovered.

· Similarly when adding a device, discovery runs continuously and devices are added as they are found. So there’s no need to re-run the discovery if you forgot to set your device in discoverable mode. Related is that the stack uses the Bluetooth v2.1 “Extended Information Response” feature to find the discovered device’s name immediately. For any pre-v2.1 devices they will still appear initially without their names with the name being refreshed a few seconds later.

· Another is the addition of “Simple Pairing”. It implement’s Bluetooth v2.1’s “Simple Secure Pairing” technology, see more below. My (old) Headset-Handsfree device pairs simply with Windows 7 without prompting the user to supply that well-known pin ‘0000’.

·         Finally is support for Bluetooth audio devices. After pairing the (old) Headset/Handsfree device it is immediately available as an output device in the Windows Audio control panels (HFP enabled on the headset’s Bluetooth Services tab, with the less capable HSP profile also listed but disabled).
    It is installed as an audio “communication device” but can be configured to be a default output device. I haven’t A2DP headphones to check whether they’re used by default for default audio. Another nice feature is that if the headset goes out of range the audio is switched to another output device, and apparently vice-versa. See the channel9 video with Larry Osterman for more information on the audio changes[ii].
    Note I have a Belkin Dongle that expects to be used with the Widcomm stack. When enabling HandsFree/Headset support it won’t use the Microsoft support for this but needs the Widcomm Vista wrapper software installed.

From presentation at Microsoft hardware conference (WinHEC 2008)

http://www.microsoft.com/whdc/winhec/2008/pres.mspx

CON-T536 — Bluetooth and Wireless USB Support in Windows 7

Connected Devices

Slide 12: Summary of what’s new in Windows 7

• Bluetooth Integration into Devices and Printers UX

• In-Box support for Bluetooth Audio

• Bluetooth v2.1 Support

• Improved Power Management

Bluetooth radio can enter Selective Suspend while connections are in sniff mode.

• USB Class Match for Bluetooth Dongles

In-box support for 100% of Bluetooth dongles.

Slide 13: Devices And Printers

Bluetooth Integration into Devices and Printers UX

• Pairing Wizard Launch Point

• Problem resolution entry point

• Photorealistic icons

• Collecting point for all devices

• Customizable context menus

• Device Stage for Windows Portable Devices (WPD)

Slide 15: Inbox Bluetooth Profile Support

Windows 7 added: A2DP, Handsfree, Headset, and AVRCP.

Previously: HID, Serial Port, OPP, PAN, DUN, and HCRP.

Slide 18: Extended Inquiry Response

(Remember that Device Discovery has: Step 1: Inquiry, Step 2: Name Discovery)

• Bluetooth v2.1’s Extended Inquiry Response (EIR) can combine steps 1 and 2.

• EIR Packet can provide, Local Name (Bluetooth Device Name), Service Class UUIDs, TX Power Level, Device ID, or Manufacturer Specific Data.

• Microsoft Windows uses EIR to supply its Bluetooth Device Name and to fetch Bluetooth Device Names.

Slide 19: Pairing in Windows Vista SP1

Basic! Either: Choose a passkey for me, or Enter a passkey.

Slide 20: Pairing in Windows 7

To a non-v2.1 device.

What’s the Bluetooth Device Class?

Device Class	Pairing method
Loudspeaker, Headphones, Headset, etc	0000
Pointing Device	No Passkey
Keyboard	Generated PIN
Display	0000
Phone	Generated PIN
Computer	Generated PIN

Slide 21: The exceptions

Back to a dialog like Vista's.

Slide 23: Pairing with a v2.1 device

Always Pairs Correctly:

Slide 24: Logo Requirements

• Bluetooth v2.1 will be required as of June 2009

• Device ID Profile is already required. It enables Microsoft Windows to determine: Vendor ID, Product ID, and Version.

Slide 26: Down-Level Support For v2.1?

Yes:

Bluetooth “Simple Secure Pairing”

To quote from The Bluetooth SIG’s press release[iii]:

“[…] For example, pairing a Bluetooth headset and mobile phone is as easy as turning on the headset, selecting “Add Headset” from the phone menu, and then watching the phone confirm it has found, connected with an encrypted link and paired the headset. To prevent any threat of a “Man in the Middle” attack, a Bluetooth device utilizing simple pairing can provide an additional security layer by generating a six-digit passkey that the user enters to verify control of both devices. This passkey is different from a PIN code in that it is provided by the initiating device and unique to each connection sequence so that the user does not have to create or retain any codes to enjoy secure communication.

“Near Field Communication (NFC) technology may also be used in the new pairing system whereby a user would hold two devices together at a very short range to start the quick pairing process.”

The white paper[iv] explains that the technology uses “Elliptic Curve Diffie-Hellman (ECDH) public key cryptography” and that four association models are defined: Numeric Comparison, Just Works, Out Of Band, and Passkey Entry.

· The Numeric Comparison association model is designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter “yes” or “no”. A good example of this model is the cell phone / PC scenario.
The user is shown a six digit number (from “000000” to “999999”) on both displays and then asked whether the numbers are the same on both devices. If “yes” is entered on both devices, the pairing is successful.

· The Just Works association model is primarily designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits. A good example of this model is the cell phone / mono headset scenario where most headsets do not have a display.
The Just Works association mode uses the Numeric Comparison protocol but the user is never shown a number and the application may simply ask the user to accept the connection (exact implementation is up to the end product manufacturer).

· The Out Of Band (OOB) association model is primarily designed for scenarios where an OOB mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process. […]
As an example, with a Near Field Communication (NFC) solution, the user(s) will initially touch the two devices together. The user may then be asked if they wish to pair with the other device and if “yes” is entered the pairing is successful. This is a single touch experience where the exchanged information is used in both devices.

· The Passkey Entry association model is primarily designed for scenarios where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.
The user is shown a six digit number (from “000000” to “999999”) on the device with a display. They are then asked to enter the number on the other device. If the value entered on the second device is correct, the pairing is successful.

For instance when I pair my (old) Bluetooth headset to my Windows 7 PC apparently the Just Works method is used —I am not prompted for the very well known pin ‘0000’.

Developer changes

In practice

Authentication

Two classes in 32feet.NET deal with authentication/bonding on Win32. The first is method PairDevice on class BluetoothSecurity which actively pairs with a peer device and is passed the device address and a pin/passphrase string. It uses native method BluetoothAuthenticateDevice, and it seems to work fine. Apparently the new BluetoothAuthenticateDeviceEx native method is only required in SSP scenarios — presumably when using Out-Of-Band pairing as it takes a BLUETOOTH_OOB_DATA_INFO parameter.

The other class is BluetoothWin32Authentication which is used to passively respond to authentication requests, e.g. when we connect to a service on a device that requires authentication, it will get an event and we can return the pin/passphrase for that device. It can be used directly but it is also used internally by a number of classes (e.g. by BluetoothClient.SetPin).

This class seems not to work on Window 7 when using the original API. I have updated it to use the new API and it now works. The code tries now to use the new API (BluetoothRegisterForAuthenticationEx) but if it doesn’t exist the code then falls back to using BluetoothRegisterForAuthentication. Similarly depending on whether we receive the new or old callback we use the old or new version of BluetoothSendAuthenticationResponse, e.g.:

// the KB942567 callback
private bool NativeCallback(IntPtr param, ref BLUETOOTH_AUTHENTICATION_CALLBACK_PARAMS pAuthCallbackParams)
{
    if (pAuthCallbackParams.authenticationMethod
            == BLUETOOTH_AUTHENTICATION_METHOD.Legacy) {
        BLUETOOTH_DEVICE_INFO bdi = pAuthCallbackParams.deviceInfo;
        return NativeCallback(param, ref bdi, true);
    }
    return false;
}

// the original callback
private bool NativeCallback(IntPtr param, ref BLUETOOTH_DEVICE_INFO bdi)
{
    return NativeCallback(param, ref bdi, false);
}

private bool NativeCallback(IntPtr param, ref BLUETOOTH_DEVICE_INFO bdi, bool versionEx)
{
    string pin = "aaaaaaaa";
    if (versionEx)
        BluetoothSendAuthenticationResponse(…);
    else
        BluetoothSendAuthenticationResponseEx(…);
    …
}

Bluetooth Events

Since Windows XP, the Microsoft Bluetooth stack can notify applications of various Bluetooth events[v] — for instance for the making of ACL and L2CAP connections, and for devices coming into and going out of range[vi].

On Windows XP I implemented code to use the Radio-In-Range event to see whether it could be used to provide ‘live’ discovery. Unfortunately I found that the event was not raised for all devices found during discovery; instead events were only seen for ‘new’ devices — and when making (ACL) connections. Thus the events were not useful. By the way, we can surmise that the event seen on discovering a new device was by side-effect — when the PC connects to it to read its Device Name.

As discussed above, in Windows 7 the built-in discovery UI uses ‘live’ discovery, so it wasn’t too surprising to find that the events now work as we’d want. When we run device discovery there’s now an event raised for every device in range (in fact there are multiple events for each in-range device). The “Windows Vista Feature Pack for Wireless” notes that new devices are added to the system discovery UI as each is discovered, so it’s likely the events work this way on Vista when that update is installed.

In 32feet.NET version 3.0 RC we use that event to add support for ‘live’ discovery on MSFT+Win32 alongside all the other platforms. We also use it to enable listing “discoverableOnly” devices in normal device discovery too. Of course on Windows XP both features will only not really work, as explained above.

LastSeen / LastUsed

This relates to the 32feet.NET properties LastSeen and LastUsed on BluetoothDeviceInfo. These were provided from the native API in struct BLUETOOTH_DEVICE_INFO and are documented to contain “Last time the device was seen” and “Last time the device was used for other than RNR, inquiry, or SDP”. On previous versions of Windows however these could contain invalid values, for instance after a discovery process LastSeen on all the returned devices contained ‘now’, even for devices that were not in range and thus were just being read from the remembered/authenticated store.

In Windows 7 the LastUsed field does seem to be valid as before, but LastSeen still seems to contain an arbitrary value.

RSSI

There still seems to way to get RSSI reading on Win32. The documentation notes that Windows is using the Extended-Information-Response API with recent Bluetooth dongles so that it can get the device name quickly. This function provides the RSSI by default, and it’s a shame that there’s no API.

Listing Discoverable devices only

A common request we receive on the 32feet.NET forums is how to list only the devices that are in range (and of course they have to be in discoverable mode). This is possible on both Windows CE/Mobile with the Microsoft stack and on the Widcomm/Broadcom stack, in fact on both platforms there are separate functions for getting the ‘remembered’ devices and for getting the discoverable devices. On Win32 with the Microsoft stack one API is used to list all types of device and there’s no way to get only the discoverable devices[vii]. There’s no change in this on Windows 7.

MSDN described

MSDN shows no changes to the Winsock Bluetooth (RFCOMM) interface nor to the discovery or service related APIs. The only changes it describes are to the authentication-related APIs.

C Header files

There are a number of relevant additions to the header files in the Windows 7 version of the Platform SDK which we show below. The only other changes are the addition of more (precise) security annotations (SAL).

BluetoothAPIs.h

Additions:

typedef enum _BLUETOOTH_AUTHENTICATION_METHOD {…}
typedef enum _BLUETOOTH_IO_CAPABILITY {…}
typedef enum _BLUETOOTH_AUTHENTICATION_REQUIREMENTS{…}
typedef struct _BLUETOOTH_AUTHENTICATION_CALLBACK_PARAMS {…}

#pragma deprecate("BluetoothAuthenticateDevice")
typedef struct _BLUETOOTH_PIN_INFO {…}
typedef struct _BLUETOOTH_OOB_DATA_INFO {…}
typedef struct _BLUETOOTH_NUMERIC_COMPARISON_INFO {…}
typedef struct _BLUETOOTH_PASSKEY_INFO {…}
BluetoothAuthenticateDeviceEx(…);
#pragma deprecate("BluetoothAuthenticateMultipleDevices")

#pragma deprecate("BluetoothRegisterForAuthentication")
typedef BOOL (*PFN_AUTHENTICATION_CALLBACK_EX)(
__in_opt LPVOID pvParam, __in PBLUETOOTH_AUTHENTICATION_CALLBACK_PARAMS pAuthCallbackParams);
BluetoothRegisterForAuthenticationEx(…);

#pragma deprecate("BluetoothSendAuthenticationResponse")
typedef struct _BLUETOOTH_AUTHENTICATE_RESPONSE {…}
BluetoothSendAuthenticationResponseEx(…);

BluetoothIsVersionAvailable(…);

Bthdef.h

Removal:

DEFINE_GUID(GUID_BLUETOOTH_PIN_REQUEST, …

Additions:

DEFINE_GUID(GUID_BLUETOOTH_AUTHENTICATION_REQUEST,…)
DEFINE_GUID(GUID_BLUETOOTH_KEYPRESS_EVENT,…)
DEFINE_GUID(GUID_BLUETOOTH_HCI_VENDOR_EVENT,…)

BTH_EIR_…        -- 16+1 of

BTH_ERROR_…      -- 12 of

#define BDIF_SHORT_NAME         (0x00000040)
#define BDIF_VISIBLE            (0x00000080)
#define BDIF_SSP_SUPPORTED      (0x00000100)
#define BDIF_SSP_PAIRED         (0x00000200)
#define BDIF_SSP_MITM_PROTECTED (0x00000400)
#define BDIF_RSSI               (0x00001000)
#define BDIF_EIR                (0x00002000)

typedef enum _BTH_KEYPRESS_NOTIFICATION_TYPE{…}
typedef struct _BTH_HCI_KEYPRESS_INFO {…}
typedef enum _BTH_AUTH_METHOD {…}
typedef enum _IO_CAPABILITY {…}
typedef enum _OOB_DATA_PRESENT {…}
typedef enum _AUTHENTICATION_REQUIREMENTS {…}
typedef struct _BTH_AUTHENTICATION_REQUEST {…}