Resultado De La Indagación En Grupos De Investigación

By trust delegation we mean that trust relations are allowed to autonomously propagate among Bluetooth devices through new pairings between the devices. One could argue that this causes trust to be spread in an uncontrolled manner among a huge set of devices. However, this can be avoided with correct handling of the pairings on a user level. Here we describe the solution for trust delegation based on symmetric keys. Another approach for automatic trust delegation is public key–based key management, which we treat in Section 9.3.2.

According to our proposed method, each device supporting the trust dele- gation method has an internal trusted group key database. The database con- tains a list with at least the following two entries for each record:

1. A group key index;

2. A secret key corresponding to the index.

Each device might be preconfigured by the manufacturer with at least one key index chosen at random and a corresponding group key. Alternatively, it is shipped with no group key at all. When the user would like to connect two devices (that have not previously been in contact with each other), here called the first and second devices, the following procedure applies:

1. The first device requests a pairing of the two devices. If the second device refuses this request, the procedure is aborted. If the second device accepts the request for pairing, the next step applies.

2. The devices decide whether a group key–based pairing or a conven- tional pairing is going to take place. This can be accomplished by spe- cifically asking the user to authorize (or reject) a group key–based pairing, or proceed according to device-specific security settings regarding this issue. If a conventional pairing is chosen, the next step is 6; otherwise the next step is 3.

3. The first device sends the list of key indexes from its group key data- base to the second device. If the group key database is empty, this fact shall be made known to the second unit.

4. The second device receives the list of indexes and checks the list against the internal list of trusted group key indexes. If the device finds a match between any of the received indexes and the internally stored list of indexes, the device chooses an arbitrary index among the matches and returns this index to the first device, and the procedure continues with step 5. If no match is found, the second device returns an indication to the first device that nothing matched and whether or not its own list is empty, and then step 6 is performed.

5. The two devices perform an authenticated key exchange. The authen- tication is based on the group key corresponding to the agreed-on index. The authenticated key exchange can, for example, be the ordi- nary Bluetooth pairing procedure with the group key used as pass-key. The next step is 8.

6. The two devices perform a manual pairing. This can be an ordinary pairing or an improved one, as we described in Section 9.1. A group

key pairing shall only be performed if the user confirms that the devices regard each other as “highly trusted.” If a group key–based pairing is to be performed, the procedure continues with step 7. If a conventional pairing is taking place, the procedure ends here.

7. If both devices’ lists are empty, the second device generates a group key and a corresponding key index, both uniformly and randomly chosen. The key and index can be of any size, but a 128-bit group key size and a 48-bit key index, for example, are the most suitable for the Bluetooth system. The procedure continues with the next step.

8. The two devices switch to an encrypted connection using the recently agreed-on secret key.

9. The second device calculates what items the first device is missing from the second device’s list of trusted group key indexes and corresponding keys. These items are sent to the first device, which will add all previ- ously unknown indexes and keys to its own trusted key database. 10. The first device calculates what items the second device is missing

from the first device’s list of trusted group key indexes and corre- sponding keys. These items are sent to the second device, which will add all previously unknown indexes and keys to its own trusted key database. This ends the procedure.

This procedure is repeated at each pairing occasion. Whenever two devices regard each other as “highly trusted,” they will exchange trusted group keys. This allows trust relations to propagate among the devices. This in turn will considerably reduce the number of manual pairings needed when several devices are going to be paired with each other.

An example

Next we give an example of how the group extension method works when only four devices are involved in the trust delegation. LetA,B,C, andDdenote the four different devices. In the example, we have assumed that the devices are not preconfigured with any group key from the start. Below we describe the four dif- ferent pairing steps. The steps are illustrated in Figures 9.6 and 9.7.

1. Two devices, A and B, are connected for the first time. No trusted group keys are stored in any of the devices and they perform a manual pairing based on a pass-key. Both users indicate that this is a pairing with a highly trusted device, and after authentication and a switch to encryption, deviceAgenerates a trusted group key with index 12and sends this index and key toB. Both devices store the trusted group key

2. Two devices, Cand D, are connected for the first time. No trusted group keys are stored in any of the devices and they perform a manual pairing based on pass-keys entered into both devices. Both users indi- cate that this is a pairing with a highly trusted device, and after authen- tication and a switch to encryption, deviceCgenerates a trusted group key with index 2 and sends this index and key toD. Both devices store the trusted group keyK2in their respective databases.

3. Two devices,AandC, are connected for the first time. DeviceAsends the index of its only trusted group key, number 1, to deviceC.Chas no key with index 1 and replies with a request for bonding. The devices perform a manual pairing based on a pass-key. Both users indi- cate that this is a bonding with a highly trusted device, and after authentication and a switch to encryption, device A sends its list of trusted group keys, that is, index 1 and keyK1to deviceC.Creplies

with its list of trusted group keys, that is, index 2 and keyK2. Device A

Device A Device C Device D Device B Pass-key pairing 1,K1 Pass-key pairing 2,K2 2. 1.

Figure 9.6 Trusted group extension example, steps 1 and 2.

2. The index should be chosen from a large space to avoid collisions. In order to simplify the description, we here just choose the indexes 1, 2, 3, and so on.

stores the new group keyK2in its database and device C stores the new

group keyK1in its database.

4. Two devices, A and D, are connected for the first time. Device A

sends the index of its trusted group keys, that is, 1 and 2, to deviceC.

Chas a key index 2 in its trusted group key database and replies with key index 2. The devices perform an authenticated key exchange based onK2. After authentication and a switch to encryption, device

Asends the trusted group keys with index 1 and the keyK1to device

D. D does not have any additional trusted group keys and just accepted the last index and key.

Implementation aspects

The trusted group extension approach can be used without the improved pair- ing proposal in Section 9.1 (even if the security is not as high as with it).

Device A Device A Device D Device C Pass-key pairing 1,K1 2,K2

Automatic pairing based onK2

1,K1 4. 3. 1 1,K1 1,K1 2,K2 2,K2 2,K2 Request pairing 2 1, 2

Together with improved pairing, it gives higher security, and, if desired, it can provide functionality similar to the public key–based key management methods we will describe in Section 9.3.2. This is achieved if personal devices are always first paired with one particular device. The trusted group extension can be implemented independently of the security modes, and the only requirement is that it is possible to distinguish between a pairing with a highly trusted device and other situations. It must then be possible on the user interface level to make the distinction between highly trusted devices and other devices.

The trusted group extension requires a slightly modified pairing protocol to be used. As with the improved pairing proposal, we have several options on where to implement the support for the new protocol. The ideal case would be to introduce a set of new LMP commands for this purpose. However, this requires changes to the Bluetooth specification or the use of proprietary Blue- tooth modules with this functionality. If this is not a possible option, the proto- col can be implemented according to the principles we discussed for the improved pairing protocol in Section 9.1.3. That is, using OBEX or defining a new IETF EAP for this purpose. The most attractive solution from a pure secu- rity point of view is to offer the trusted group extension as part of the improved pairing functionality.

Introducing several security groups

The trusted group extension method can be used to propagate trust relations among units in an ad hoc fashion. So far, we have only considered trust propa- gation for one uniform group. The trust relations can only be extended within this single group. If only one group is allowed, there is a risk that this group is extended rapidly without control. If this happens, the security of the system is compromised. Hence, it must always be possible for the user to reset the trusted group key database (and possibly the link key derived in this group) of the device, and in that way damage can be avoided. Thus, for the group extension method to be secure, the user must be very careful with extending the security group. Furthermore, in some scenarios we would like to create, for example, temporary groups or groups with different rights. Then, in order to maintain a good security level, one must allow several different groups to be created. Each group can be created with a special purpose and with certain security limita- tions. For example, one can limit the lifetime of the group and/or the security policy for the members of that group. This can be done in accordance with the PAN security domain ideas introduced in [7].

Supporting several different security groups creates additional require- ments. Group key indexes and the link keys obtained from pairings or key exchange in a group must be stored together or must be marked. Furthermore, a user-friendly name should be associated with the group. It is only when manual pairing applies that the user must be involved in choosing the right group. On

the protocol level there, it must be possible to deal with the different groups and group extensions for the different groups. This means, for instance, that each group must be authenticated separately, before the group keys should be spread. We do not deal with the detailed requirements or solutions for supporting sev- eral security groups here, but leave the details of such solutions to people inter- ested in implementing such a feature.