The present invention relates generally to communication systems, and more particularly to managing Bluetooth devices.
Bluetooth wireless technology is a short-range communications system intended to replace cables connecting portable and/or fixed electronic devices. Two or more Bluetooth devices can communicate over an established wireless network, also known as piconet. All devices within a piconet share the same physical channel for sending and receiving data. Typically, each piconet has one device acting as a master device, while all other devices act as slave devices. Establishing communication, whether as a master device or a slave device, is carried out by the individual devices themselves. There is no central authority that dictates which device can or cannot communicate with another device.
Bluetooth does not provide a managed solution. In other words, there is no central authority that can control which Bluetooth devices can connect with which other Bluetooth devices. As an example,
Secure communications between Bluetooth devices may require the devices to establish a pairing. Two Bluetooth devices are paired when they share a key that can be used to communicate securely. Once paired, the two devices can encrypt communication data based on the shared key. Each device maintains the pairing even after initial communication with that device terminates so that the already established pairing information can be used for secure communications in the future without re-executing the time consuming pairing process. Certain applications require a device (e.g., cell phone, laptop computer, etc.) to communicate with several other devices. Thus, each device will have to maintain several pairings in memory. For devices with limited memory capacity, storing all pairing information associated with all the devices it has paired with may not be possible.
Furthermore, devices such as cell phones and laptop computers are frequently replaced due to failure, loss, upgrade, or other reasons. A replacement device may not contain any pairings that the original device had in memory. Thus, a user carrying the replacement device would have to re-pair the replacement device with each device it communicates with. This process can be tedious and burdensome to the user, especially if the user is inexperienced with Bluetooth technology.
A system and method for managing Bluetooth connections between Bluetooth devices is presented. A first Bluetooth device can have a virtual Bluetooth device associated with it. A virtual Bluetooth device can include Bluetooth parameters and values that when adopted by a second Bluetooth device, would allow the first and second Bluetooth devices to begin communicating as already paired devices. The first and second Bluetooth devices can be fixed or mobile devices. The first Bluetooth device can be configured to allow a Bluetooth connection with the second Bluetooth device only if the second Bluetooth device has the Bluetooth parameters associated with the first Bluetooth device. One of the parameters of the virtual Bluetooth device can include a secret key, or link key.
An administrator can control the access to a Bluetooth device by controlling access to the associated virtual Bluetooth device. The administrator can be a server maintaining access privileges of one set of Bluetooth devices to another set of Bluetooth devices. A Bluetooth device can identify another Bluetooth device by any method other than Bluetooth. This can include RFID, bar code, etc. Once the Bluetooth device has been identified, the identity of the Bluetooth device can be sent to the administrator server with a request for its associated virtual Bluetooth device. The administrator server can reply based on access privileges. Alternatively, the administrator server can allow a Bluetooth device to store virtual Bluetooth devices associated with all the Bluetooth devices that it has permission to access. As a result, the Bluetooth device need not contact the administrator server each time it needs to connect to another Bluetooth device.
The two Bluetooth devices can begin establishing Bluetooth connection as already paired devices. Because the two Bluetooth devices know each other's identity, they can skip the Inquiry stage of the Bluetooth connection process and establish a physical link. Also, because the secret key, or the link key, is known by both devices, they can skip the time consuming Pairing step and establish a logical link. The devices can then perform one-way or two-way authentication using the shared link key. After authentication, the two devices can begin secure communication.
Access privileges for a Bluetooth device can be dynamic, i.e., they can change over time. The administrator server can control access of virtual Bluetooth devices based on the changing access privileges. This can involve denying request for virtual Bluetooth devices associated with inaccessible Bluetooth devices. Additionally, the administrator server can communicate with a Bluetooth device to add or delete virtual Bluetooth devices stored in the device's memory.
Exemplary embodiments of the present invention will be more readily understood from reading the following description and by reference to the accompanying drawings, in which:
Parameters for both VMD and fixed device can also include BT profiles. BT profiles specify the required functions and features of each layer in the Bluetooth system, which layers can include PHY (physical layer), Baseband, Link Manager, and L2CAP (logical link control and adaptation protocol), and any additional layers such as application layers. Such profiles can include the Generic Access Profile (GAP), Generic Attribute Profile (GATT), etc. BT profiles can, for example, determine whether the device is to communicate using Basic Rate or Low Energy state. Additionally, profiles can instruct the fixed device, for example, to establish communication with only those devices whose BD_ADDR is same as the one for the corresponding VMD. Additionally, the profiles can instruct the mobile device that adopts the VMD parameters to use the BD_ADDR specified in the VMD as its own address.
An administrator can control accessibility to fixed devices by determining which mobile devices can have access to a particular VMD. For example,
A mobile device can access a fixed device only if it is able to access the VMD associated with that fixed device. The administrator can therefore control access to fixed devices by way of controlling access to their associated VMDs. For example, referring again to
Although
The administrator can provide access to VMDs in a number of ways. In one way, the administrator can upload and store VMDs in the mobile device's memory.
In another way, the server 407 may send only a single VMD to the mobile device 251. For example, the mobile device 251 may identify the particular fixed device it wishes to be connected to and send the fixed device identity to the server 407. Upon receiving this request, server 407 can check the access privileges of mobile device 251 for the identified fixed device, and if allowed, server 407 can reply with the VMD associated with that fixed device only.
Mobile device 251 can identify a fixed device in many ways. In one way, the mobile device can include a scanner, such as a bar code scanner, while the fixed device can have its own identity encoded in a machine readable format, such as a bar code, affixed on or near the fixed device. The mobile device 251 can then use the scanner to scan the identity of the fixed device. Alternatively, other ways of identification, such as radio frequency identification (RFID) devices, infra-red (IR) badges, laser readable IDs, etc., can also be employed. The mobile device 251 may also use global positioning system (GPS) or other location identifying system to determine the mobile device's proximity to a fixed device. When the mobile device 251 is within a predetermined distance (e.g., 1-3 ft.) from the fixed device, the mobile device 251 can automatically identify the fixed device without any action from the user. Thus, the mobile device 251 can identify the fixed device based either on active user identifying action (e.g., scanning bar code, IR badge) or with passive user identification action (e.g., bringing mobile device closer to RFID tag, GPS, etc.).
Once the fixed device has been identified, the mobile device 251 can acquire the VMD associated with the identified fixed device (step 502). The VMD can be accessed from memory (
In step 503, the mobile device 251 can begin setting up a connection with the fixed device.
During paging 602, the fixed device 202 and the mobile device 251 can establish a physical channel and then a physical link between them. Establishing a physical channel means that the two devices are synchronized over a RF hopping sequence. The hopping sequence is pseudo-random in nature and is derived from the BD_ADDR and clock of the master device. Either the fixed device 202 or the mobile device 251 can assume the role of a master device. Additionally, master/slave roles can be switched at any time. Assuming that the mobile device 251 is the master, the mobile device can transmit page train messages on the derived hopping sequence. Each page train message can include a device access code derived from the BD _ADDR of the slave device, i.e., fixed device 202. In this manner, only the fixed device 202 can accept these page train messages. The fixed device 202 has the BD_ADDR of the master device, and can therefore determine the same hopping sequence as determined by the mobile device 251. Although all Bluetooth devices include the same clock frequency of 3.2 kHz, they may drift due to differences in manufacture, temperature, etc. Therefore, the fixed device 202 can use the page train messages (specifically, the device access code) to synchronize its clock with the mobile device clock by incorporating a clock offset. Once the synchronization is complete, a physical channel can be said to have been established. The mobile device 251 and the fixed device 202 can then move on to establishing a physical link by communicating on alternating master and slave transmission time slots over the established physical channel. Note that the fixed device can also store the value of the clock offset that allows the fixed device to synchronize with the mobile device. In such cases, it may not be necessary to even enter the paging procedure.
In the connection 603 stage, the mobile device 251 and the fixed device 202 can establish additional logical transport and logical links on top of the already established physical link. These can include transport and link layers such as Asynchronous Connection-Oriented link (ACL), ACL control logical link (ACL-C), User ACL link (ACL-U), etc. The fixed device 202 and mobile device 251 can use their respective BT link managers (LM) to setup the links with link manager protocol (LMP). For example, the LM of mobile device 251 can send the command LMP_host_connection_req to the LM of the fixed device 202 for requesting an ACL connection. Subsequently, the LM of the fixed device 202 can reply with the message LMP_accepted indicating that the request to establish a connection has been accepted.
For two devices that do not have a Link key, the connection setup will enter a pairing procedure 604 that allows the two devices to generate and share a Link key. Generally, this procedure takes anywhere from a few milliseconds to a few seconds. But the fixed device 202 and the mobile device 251 already have a shared link key. Therefore, the fixed device 202 and the mobile device 251 can skip the pairing procedure 604. Instead, the fixed device 202 and the mobile device 251 can go ahead and exchange messages that indicate that an ACL connection setup has been completed.
The fixed device 202 and the mobile device 251 can then authenticate each other. The authentication can use a challenge-response scheme in which a device's knowledge of a secret key can be checked through a 2-move protocol using symmetric secret keys. For example, the fixed device 202 can generate and send a random number AU_RAND to the mobile device 251. The mobile device 251 can use AU_RAND, the BD_ADDR of the fixed device, and the Link key as an input to an authentication code to generate a result SRES, and send the result to the fixed device 202. The fixed device can use the AU_RAND, the BD_ADDR of the mobile device 251, and the link key as an input to the same authentication code to generate SRES′. If the SRES generated by the fixed device 202 is the same as the SRES′ received from the mobile device 251, then the mobile device 251 is considered to be authenticated by the fixed device 202. Alternatively, the above described one way authentication can be initiated by the mobile device 251 instead of the fixed device 202. In other words, the mobile device 251 is the one that generates and sends the random number AU_RAND to the fixed device 202 and verifies the received result SRES. Two-way authentication can also be carried out, in which both the fixed device 202 and the mobile device 251 carry out separate one-way authentication operations to authenticate each other. If authentication fails, for example, when SRES is not equal to SRES′, the fixed or mobile device can abort the establishment of the Bluetooth connection.
Once a Bluetooth connection is established, the mobile device 251 and the fixed device 202 can begin secure communication using the common Link Key in step 605. All data between the mobile device 251 and the fixed device can be encrypted by the Link Key or another mutually agreed key derived from the Link Key.
Other logical channels using protocols such as L2CAP (logical link control and adaptation protocol), can also be established. L2CAP provides a multiplexing role allowing many different applications running on the devices to share an ACL logical link. Applications on one of the two devices interface with L2CAP using channel-oriented interface to create connections to equivalent entities in the other device. Data associated with these applications can employ the secure connection setup in step 605.
While
Each of the mobile devices 701-704 can have its own identity encoded in a machine readable format, such as a bar code, affixed on or near the mobile device. While each fixed device 711-714 can have a bar code scanner for identifying a mobile device. Previously discussed identifying methods such as RFIDs, GPS, etc. can also be employed.
Permissions for accessing VFDs can be maintained at an administrator server. A table similar to the one shown in
Another example of establishing communication between two Bluetooth devices can exclude the use of identification methods such as RFID, bar code, GPS, etc. In such an example, in contrast to that shown in
Access privileges associated with Bluetooth devices can change over time due to devices being lost, non-functional, or because access policies have changed. As a result, permissions stored at the administrator server, for example, in
A person skilled in the art will appreciate that in the embodiments discussed herein, access to a Bluetooth device can be controlled irrespective of whether the device is a fixed device or a mobile device. The distinction between a fixed device and mobile device has been maintained here to aid discussion and in no way limits the scope of the invention to such devices. To the extent that certain details of Bluetooth devices have not been discussed, such details can be found in the Bluetooth specification available at the Bluetooth website.
The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of this disclosure. The scope of the invention should therefore be determined not with reference to the above description, but instead with reference to the appended claims along with their full scope of equivalents.