Messing with My BT Keyboard

btkybrdtest1Figure 1:  XU4 powering My favorite BT keyboard.

So, I have a keyboard that uses the Bluetooth 3.0 protocol.  I decided to use it on my newest homemade tablet: the Odroid XU4 powered one I’m in the process of building.

I’m inherently distrustful of GUI interfaces that want you to click them for that all-in-one-click magic of making connections to things.  “What did it do really?” always echoes in my mind.  So, I like to kill the GUI apps, and do it by hand.  Running Ubuntu, that is not very hard to do, and results in an appreciation for what’s happening (plus or minus).

The first thing I did was to install bluez-tools and bluez-hcidump packages from the Ubuntu Repo.  Then, I made sure the BT dongle was lit up in blue (see photo), turned the keyboard on, and executed:

  • sudo hcitool scan

The hcitool program spit out the address of my keyboard: xx:xx:xx:xx:xx:xx (my real address is not shown here).

I then proceeded to use a command I had used in the past for such things:

  •     echo 1234|bluez-simple-agent hci0 xx:xx:xx:xx:xx:xx

Yes, “1234” is a silly PIN number.  As it turns out, other PIN numbers are silly, and in fact all PIN numbers are silly.  Still, I shouldn’t use “1234” – I now admit, if for no reason other than not training myself to teeter on the edge of slippery slopes.  These days they’re telling us not to use PIN pairing, and to use SSP pairing instead.   So, I guess we’ll end up with SSP, and most of this post is to convince myself that I actually can know which modes are being used, whatever they are.

Ubuntu reported that the bluez-simple-agent file was not found.  A peek at the pages of a Linux forum post revealed that the bluez software had been upgraded, and that it was necessary to use some other command for similar results:

  • sudo bluetoothctl -a

This command put’s the user into an interactive shell, where command syntax can be illuminated with the “help” command.  Typing “list” showed me the local controller info, and typing “scan on” found both the local controller, and the remote BT keyboard, and displayed their addresses. For clarity, I’ve colored regular commands green, and interactive bluetoothctl commands to be blue in color:

  • scan on

The output of the “scan on” command gave me the address of the keyboard (xx:xx:xx:xx:xx:xx), which I could then supply as an argument for other commands.

Typing info xx:xx:xx:xx:xx:xx displayed the info for the keyboard, whether or not it was paired (no), trusted (no), blocked (no), connected (no), or using legacy pairing (no).

  • info xx:xx:xx:xx:xx:xx

The info command output is nice, orderly, and inspires more confidence than the “connected” single line output typical of GUI oriented one-click setups. Of course the GUI does all this in the background.  Of course it does.

Typing “paired-devices” lists the devices that are paired.  As was indicated by the “info” command, there were no paired devices.  At this point, I opened another terminal and typed the command:

  • sudo hcidump -X

This terminal allowed me to watch the proceedings, as the pairing and connection operations were carried out.

Even though I hadn’t at this point specified a pairing mode (other than by allowing the default), or an authentication level (other than by allowing the “unknown to me” default), or encryption (other than by allowing the default), and knowing that I needed to check those things out thoroughly before actually using my keyboard for anything, I proceeded with a test pairing. I guess I just wanted to see what the defaults would do. The pairing mode (especially if it were SSP) would seem to imply the use of encryption. Going back to the original terminal and the BT shell environment, I typed:

  • pair xx:xx:xx:xx:xx:xx

The program dutifully paired the keyboard, and displayed a message to that effect.  But, at this point, how much better off was I, as opposed to using the one-button-click method? Really, I was only slightly better off,  in terms of knowing what was going on, since I could follow the progress of things in the second terminal, which was running hcidump.  But, what did I know about how my keyboard was paired?  It would be necessary to dig deeper to determine the answers to that question.

I issued another info command:

  • info xx:xx:xx:xx:xx:xx

Resulting output: paired: yes; legacypairing: no, trusted: no; blocked: no

So, the indications were that I had an SSP pairing. But, the details were sparse, and I didn’t really want to allow a connection from the keyboard, without more info about the authentication and encryption. I was using the defaults, which generally isn’t a good idea IMO. To explicitly set the pairing mode, I could have issued:

  • sudo hciconfig hci0 sspmode 1

But, for the purposes of a test, I allowed the use of the defaults:

  • connect xx:xx:xx:xx:xx:xx

It connected.  So, how did it connect? Did it have the proper authentication and encryption going on? How to verify the detail of all that?

  • sudo hcitool con
  •    — ACL xx:xx:xx:xx:xx:xx
  •    — Handle 11 state 1 – lm MASTER AUTH ENCRYPT

Are the values shown indicative of the capabilities or the “state” status of the device? It kinda looks like state. But, I’d like to see some verification of all this stuff.  All the details. Again, I could read the specification.  There are things to know. What’s the key strength? What are the algorithms? Etc.  Etc.

With SSP, encryption seems to be intrinsic to the pairing mode.  So, maybe once the pairing mode is set, there’s no need for explicitness in that regard.  But – I don’t know for sure. Maybe lack of explicitness breaks something, and it needs to be done anyway.

I used the hciconfig program in another terminal to explicitly set encryption “on”:

  •           sudo hciconfig -a hci0 encrypt
  • Write Encryption Enable 0x03|0x0020 ncmd 1 status 0x00
  • Write Encryption Mode 0x03|0x0022 ncmd 1 status 0x00

(Note: AFAIK the devices need to be re-paired for this to be effective)

Had any modes been previously specified by the defaults?  I executed the command again:

  •     sudo hciconfig -a hci0 auth
  •           sudo hciconfig -a hci0 encrypt
  • Write Encription Mode 0x03|0x0022 ncmd 1 status 0x00

(Note: AFAIK the devices need to be re-paired for this to be effective)

I re-paired the devices. Why were there differing results?

In the olden days, they used what is now called “legacy mode” pairing.  One form of legacy mode pairing is PIN pairing (they’re saying not to do that anymore).  If I had wanted to do a PIN pairing, then before trying to pair anything, maybe I could have executed:

  • hciconfig hci0 sspmode 0

Again, they’re saying not to do that kind of pairing anymore. Note that these things are all keyboard device dependent. Some keyboards may not do PIN pairing when the aforementioned command is executed. My particular keyboard, when used with my particular system, seems to be defaulting to SSP and not any legacy mode: sspmode=1 (on).  In other words, if I don’t set a mode explicitly, then when I execute:

  • info xx:xx:xx:xx:xx:xx

      The resulting output is:

  • Bluetooth Keyboard
  • Class 0x002540
  • Icon: Input-keyboard
  • LegacyPairing: no
  • paired: yes
  • trusted: no
  • blocked: no
  • RSSI: -10

This result might not apply to other keyboards and/or other systems. It’s better not to use default values, IMO.  But – I’m not an expert in this matter. To explicitly set the pairing mode to SSP, maybe I could have executed:

  • sudo hciconfig hci0 sspmode 1

Note that the hciconfig commands do not result in persistent settings.  So, if there’s a reboot, the commands would need to be re-executed (or the settings would need to be put into a config file, or the commands executed in a startup script).  Anyway, it seems not prudent to rely on defaults.  I did allow the defaults, in this case, and my (particular) Ubuntu system used SSP mode, making a non-legacy, non-pin-mode connection.  But, I received very little feedback about it.  No warm fuzzy at all.  If I decided to “trust” the keyboard, after the successful pairing, then while in the interactive environment, I could have issued:

  • trust xx:xx:xx:xx:xx:xx

That would mean the device would connect automatically anytime it was turned on, and within range.  But I’d really have to trust the device to feel good about that.

Maybe to satisfy myself completely, I need a bluetooth protocol analyzer, so that I can look at the lower layers where the encryption is happening.  I can currently use wireshark to look at https traffic and convince myself that it is properly encrypted.  I’d like to do something similar for bluetooth. I just don’t like to assume anything.

Going back the the hcidump terminal, I can look at the output to see what’s passing by in the little window. It’s obtuse looking stuff.  Eye watering series of HCI commands, and RFCOMM/L2CAP protocol details, and application data.  Without having memorized the specification for all of this, it’d be tough slugging.  So, I found a suggestion on the net, for using wireshark to sort it out.

Read More …

This page is presented as the work of a hobbyist, and is not meant for duplication by others.  Readers should look elsewhere for advice.  These tidbits are things I’ve done, that may or may not have worked for me, but are not suggestions for others to follow.

Bluetooth is a trademark of the Bluetooth Special Interest Group, and is not affiliated with this author or site in any way. Bluez is a software project located at bluez.org and this author and site has no affiliation with it.