The Bluetooth/USB device acts as a bridge between the mobile phone and the PC. It will receive data over the Bluetooth interface and send this data through the USB port to the PC as an emulated keystroke. The first thing a user needs to do to start using the single sign-on system is to plug the Bluetooth/USB device into the USB port on the PC. The devices is among other things equipped with two LED lights. These lights are used to inform the user of the devices state. When the two LED’s starts blinking alternately, the USB device is configured properly and ready to receive data.
Any USB device connected to a PC needs to go through an enumeration process7 During the enumeration process the demo board will tell the PC that it is a device in the major class Human Interface Device (HID) and the minor class Generic Desktop Keyboard. Also the device will inform the PC on how the format of the reports will be. Reports are the packets of data the USB device sends to the PC. For the communication between the PC and USB device to work properly, the operating system must know the 7This is a process where the USB devices tells the PC what type of a device it is. If the device belongs to any
of the predefined device classes, the computers operating system will automatically load the correct driver. The enumeration process is described in detail in [11].
A mobile single sign-on system
Figure 5: Overall use case for the prototype
Figure 6: Sequence diagram for the prototype
length of the report being sent. This information is passed to the PC in the form of a device descriptor. The descriptors used to configure the device as a keyboard are included in appendixB. According to the HID specification [52] the recommended length of a report containing keystrokes is eight bytes. The report has the following format [52]: 0 Modifier Keys 1 Reserved 2 Keycode 1 3 Keycode 2 4 Keycode 3 5 Keycode 4 6 Keycode 5 7 Keycode 6
In the first of element of this eight byte report the modifier keys are stored. Modifier
keys are keys such as CTRL, ALT SHIFT etc. Each of these modifier bits are assigned a bit value8. If no modifier keys are pressed, this field is set to 0. If one modifier key is pressed, the bit value will be stored in the modifier keys field. However, if several modifier keys are pressed simultaneously, for example CRTL and ALT, the two bit values are ORed together and the result is stored in the modifier keys field.
Field 2 to 7 (field 1 is not used) can contain 6 different keystrokes. The report supports more than one simultaneous keystrokes. This is because a user is allowed to press several keys at the same time, something which is common in games. In the prototype developed in this thesis, only one keystroke will be sent in each report. This is because the input should work just as if a user was typing the characters directly on a keyboard. And when a user types, he presses one key, releases it and then presses another key. However some characters can only be displayed by pressing multiple keys at the same time. For example to type the } character on a Norwegian keyboard, the user has to press CRTL, ALT and the 0-key simultaneously. To emulate this character, the bit values of CRTL and ALT have to be OR-ed together and added to the modifier keys field. Additionally the Keycode 1 field will contain the keycode of the 0-key. The fields not in use will have the value 0. This means that if for example the character ’e’ is to be sent to the PC, all the fields would be set to zero except the Keycode 1 field that would contain the keycode for ’e’. Also it is important to send an empty report (with all fields set to zero) to the PC after each character is sent to indicate a key up event. If this key up report is not sent, the PC will think that the character is still pressed and display it to the screen continuously. It will not stop until it receives a report telling it that no keys are pressed.
Mapping between an ASCII character and a keycode is done on the MIDlet. How this mapping is performed is described in the next section.
The functionality of the USB device is actually quite simple. Once the device is cor- rectly enumerated the board sets up the USART interface. This interface communicates with the RS232 serial COM port. The f2m device described in section4.2is connected to the this port. As described in the next section, the MIDlets sends data over the serial port profile in Bluetooth. This is a protocol that emulated RS232 communication over Blue- tooth. Which means that the Bluetooth communication is transparent to the USB board. The f2m device handles everything that has to do with Bluetooth. The data forwarded to the USB board over the RS232 interface looks just like any other serial communication traffic. This means that the USB demo board does not see any difference between this emulated serial traffic and normal serial traffic passing through a standard RS232 cable. When this interface is set up, the card registers an interrupt function which is set up to listen on the RX (receive) pin of the RS232 interface. Each time a byte is received on the RX pin, the interrupt function is evoked. This function reads the byte and stores it in a globally available circular buffer. The MIDlet sends one byte at the time. When the ring buffer contains 8 bytes or more, another function is invoked. This function reads 8 bytes from the buffer and places them in the input report. When the report is ready, it is sent to the PC, and the character is displayed on the screen. This process will continue until the buffer is empty and all the characters are displayed.
A mobile single sign-on system