5.5 Extended Bootstrapping: Creating the Initial Key-Graph
In the last sections, we presented an extended algorithm for obtaining our key graph and estab-lishing new keys between devices. In addition, we discussed in Section3.4different approaches for creating the initial key graph. Remember, that the initial keys need to be distributed over a secure channel, i.e. out-of-band. However, due to the extended requirements of this approach we need to adapt our basic bootstrapping approaches. In the following we describe the exten-sions to the already introduced bootstrapping possibilities.
5.5.1 Static Pre-Distribution
The classical pre-distribution works similar as described before with the basic algorithm. Hence, the manufacturer of a network stores the initial key sets on the devices before deploying the network. The only difference to the basic bootstrapping method is, that the manufacturer now needs to store the keys on devices using Algorithm 5.1 and therefore creating a key graph which is compatible with our recursive key establishment algorithm. Thus, this approach has the same advantages and disadvantages as the basic bootstrapping approach which is described in Section3.4.1.
5.5.2 Configuration Device
As before the usage of a configuration device is another possibility to introduce new devices to a network. We presented already in Section3.4.2the basic principle of such a configuration device.
In the basic bootstrapping the configuration device only needed to pick randomly s devices to place a key with a new device. However, in the extended bootstrapping process it cannot choose completely randomly since it needs a valid s-connector.
Hence, the question remains how such an s-connector can be found by the configuration device.
At least two possibilities exist. The simplest method is that the configuration device stores a global view of the network. This can be done by always remembering the device IDs which have been used when introducing a new device. However, the global view would become in-consistent if devices are removed without also updating the global view of the configuration device. Due to this drawback we favor the following approach: Whenever a new device is introduced into the network, the configuration device picks one device from the network ran-domly. As already mentioned, each device is part of an (s + 1)-clique, hence it has knowledge about s different s-connectors with the device itself as a part of the specific s-connector. The configuration device requests one of theses s-connectors from the device. The device might
randomly choose one s-connector, i.e. the remaining (s − 1) device IDs, and then send this in-formation back to the configuration device. With this inin-formation, the configuration device can now complete the introduction of the new device.
The configuration device method for bootstrapping has the same advantages and disadvantages as described in Section3.4.2. With the extended algorithm, there is an additional communica-tion overhead for communicating a valid s-connector.
5.5.3 Physical Contact
In Section3.4.3 we introduced also a user-driven method, where the user is responsible for exchanging the first s keys for a new device. The preferred method for exchanging a new key between two devices by the user was to bring the two devices in physical vicinity and then initiate the key exchange over a secure channel (e.g. a cable). However, this method is based on the fact that the user could choose s devices randomly, which is no longer true for our extended approach. With our extended approach, the user must choose a valid s-connector. Since the user cannot be expected to know which set of devices form together an s-connector, we need some additional mechanisms to help the user.
In the following we describe two possibilities for solving the extended bootstrapping problem with physical contact. First, we describe a simple method which is very similar to our extension in the last section with the configuration device. Second, we describe a more complex method, where the user again is free to use s random devices.
Manual
Whenever a device is introduced in the network, the user randomly chooses a device already in the network and establishes a new key in an out-of-band secure way e.g. via a secure physical connection. From this point on we proceed similar as in the method with the configuration device: The contacted device from the network sends the IDs of s − 1 devices that form together with the device itself an s-connector to the new device. The new device displays them to the user, e.g. on a small display, who can now choose further (s − 1) devices and finish the introduction process in the same way as for the first device. Having established a new key to the other devices, the new device is fully introduced in the network and can use our recursive key establishment algorithm to establish any further keys.
Consider the example from Figure5.8. Device H needs to be introduced to the already existing network (devices A − G). Therefore the user first exchanges a key with the randomly chosen de-vice F by physical contact. After having this first key, H can communicate securely with F and requesting the first s devices from F (Figure5.8(a)). F responds with B and D (Figure5.8(b)).
5.5 EXTENDEDBOOTSTRAPPING: CREATING THEINITIALKEY-GRAPH 125
This information needs to be communicated to the user, e.g. by displaying it on a display. Now, the user knows with which other device he needs to further establish a key in order to introduce the new device. In the example the user chooses device B (Figure5.8(c)).
(a)
Figure 5.8: Introducing a new device to the network (s = 2)
Automatic
After choosing randomly the first device with the manual physical contact method, the user needs to use (s − 1) specific other devices for introducing a new device. However, some of those devices might not be easy reachable. Therefore we developed a small extension, which allows the user again to choose all s devices randomly.
The automatic physical contact method is based on the fact that our RKEA itself can be used to correct the primary key set on a newly introduced device. With this method the user establishes new keys with s randomly chosen devices of the network. Even if this results in the new device not being connected to a valid connector, the new device can request as before a valid s-connector of one of the devices to which it already has a key. After obtaining this information, it can – just like in the manual case – establish new keys to this s-connector, but unlike in the manual case, using RKEA. Having established new keys with a valid s-connector, the initial keys exchanged by the user can be removed. Hence, the difference to the manual case is that the user only needs to exchange s keys when introducing the new device and the device itself will establish keys to a valid s-connector.
The automatic approach – using RKEA with a device which is not connected to a valid s-connector – is sound for the following reason: The initial contacted devices are already part of the network and can therefore establish a key with any other device of the network. When these devices have all established a key to the same device, the new device can do so as well, since it now has s intermediary nodes to the device. Thus a device, even if not yet fully introduced, can establish new keys to devices in the existing network – thus establishing keys to an valid s-connector.