IBSS Ad-Hoc Networks
Several times we have mentioned IBSS networks, also called
ad-hoc networks, and deferred discussion on the security issues. This section
finally looks at these issues in detail and discusses a solution that may be
available. At the time of writing, WPA does not provide a security solution for
IBSS.
Chapter 7
discusses the security context. Security
operations take place within a limited context that has a clear start and end.
In other words, the context is created by some actions and closed by some other
actions. This approach maps quite well into networks with an access point
because the access point has master control of the local network. It is a place
where the authenticator can reside and all the mobile devices can establish and
break a security context with that authenticator.
The major advantage of an IBSS network is that there is no
master device. All devices have equal status and any device can talk to any
other device. This is also the major problem with IBSS networks from a security
standpoint.
First, let's quickly review how an IBSS network operates.
Suppose a group of people get together in a conference room for a meeting and
they want to share information among their laptop computers. They agree on an
SSID or network name that they will use for their meeting and configure it into
their laptops, specifying IBSS operation. When the first laptop is enabled, it
starts looking for beacons containing the target SSID. It ignores beacons from
access points and looks only for beacons from other devices in IBSS mode. If it
doesn't see any beacons, it realizes that it is the first arrival and starts
sending beacons itself.
The next laptop to turn on sees the beacon from the first
laptop, with the correct SSID, and synchronizes its timing. Now the two devices
may share the process of sending beacons according to an algorithm defined in
the IEEE 802.11 standard. If the first station goes away, the second one sends
all the beacons by itself. If any device has a broadcast message to send, it
just transmits and all the others listen. If any device wants to send a frame to
another device, it just transmits with the target device's MAC address as the
destination. Note that there is no process of association and devices can come
and go as they please without any hellos or goodbyes.
In our simple example, this works very nicely. All the people
in the conference room are within range of each other and all the laptops can
communicate. If somebody goes out of range, they are cut off; there is no
concept of roaming. Now we come to the security problem.
The conference participants might realize that their session is
incredibly insecure. Not only can outsiders see their data, but anyone can join
in the network just by observing the SSID over the air. What they would like is
to agree on a password at the start of the meeting, limit access only to those
who know the password, and encrypt the data. On the face of it, this seems
straightforward, but what does it mean to "limit access to those who know the
password"? Because there is no coordinator, every mobile device has to block the
unwelcome newcomer and because there is no association, how do you set up
encryption that needs things like sequence numbers and exchanges of nonces?
This is the problem with IBSS. Intuitively, it seems simple to
share a password around the table and just encrypt the data with it. But good
security is never simple. It's easy to say things like, "Oh well, it's good
enough for this application; after all, meetings only last an hour or so." But
this is the path that leads to problems, as we saw with WEP. Eventually people
use the technology in areas in which it is "no longer good enough" and then
security breaches occur. Consider that some people have proposed to use IBSS
mode to implement ad-hoc neighborhood mesh networks for broadband connection to
the home. A simple solution that might be good enough for short meetings will
certainly fail in such an application.
There are solutions that can work and are secure.
Unfortunately, they are not simple. The current proposal for IEEE 802.11i works
as follows. First, let's assume that every mobile device has two personalities.
When it wants to talk to another device, it assumes the role of a supplicant.
When someone else wants to talk to it, it assumes the role of an authenticator.
Think of a football team playing at home or away; the mobile device is either
visiting (as a supplicant) or hosting (as an authenticator). This is shown is Figure 13.2, in which the role played by the
device depends on the direction of communications.
Now that we have established the roles of supplicant and
authenticator, we can apply the principles of IEEE 802.1X. Of course we can't
use upper-layer authentication because there is no way to attach to a common
authentication server. However, we can use a preshared key, which is quite
appropriate for the meeting case in which the master key is distributed
verbally. Once we have the preshared key and IEEE 802.1X in place, we can almost
use the same approach for IBSS as we did for ESS. We can use the four-way
handshake to establish pairwise keys, including the exchange of nonces. We can
also use the Information Element to establish the starting value of the sequence
counter. "Almost" is the operative word here because there are a couple of
problems yet to solve.
The first issue is that, if we follow this model to the letter,
we have to establish separate pairwise keys for each direction of communication.
There are two supplicants and two authenticators, which is inefficient and
unnecessary. Therefore, the device with the lowest MAC address goes first and
establishes the temporal keys, and then the authenticator in the other direction
uses the same set without further ado.
The second issue is more difficult. What do we do about the
group keys? Intuitively, you would think that the group keys would be shared by
all the devices in the IBSS. However, there are a number of problems with this
approach. Who would be responsible for creating the group key given that there
is no master? And how does the group key get distributed to everyone when you
don't know who else is out there? To solve this problem, we need to go back to
first principles and remind ourselves of the purpose for the group key. It is to
protect multicasts and broadcasts, not to allow "any to any" communication.
Multicasts are one to many communications, not
many to many.
In the case of an ESS network, the "one" is always the access
point. In the case of an IBSS network, the "one" is the device currently
transmitting the multicast. It follows that there can be a separate group key
for each mobile device that is used only when that particular device is sending
a multicast. Providing all the intended recipients (the "many") know the
sender's group key, they can receive the message. The sender is now responsible
for maintaining its own group key and for delivering it to all the other devices
with which it has a pairwise key relationship.
So now we have the IBSS security solution. It is complicated.
Ironically, the fact that ad-hoc networks are so simple to set up makes them
more complicated to secure. In summary, the process is as follows
-
The first device starts up and begins beaconing.
-
The second device starts up, detects the beacons, and
synchronizes.
-
Whichever device has the lower MAC address now acts as a
supplicant and authenticates to the other device using IEEE 802.1X. It then
performs the four-way pairwise handshake to establish temporal keys derived from
a shared master secret.
-
Both devices now send the other their group
key.
At this point the two devices can communicate privately. Now a
third device arrives and wants to join the network. It must first synchronize
and then perform separate pairwise key handshakes with each of the two existing
devices. It must then share its group key with both the other stations and
receive a group key from each of them. It has to remember five sets of keys
(including its own group key).
At this point you start to see the complexity. In general, if
there are N devices in the ad-hoc network, each must keep track of 2*N–1 keys.
So for 16 devices, you need to track 31 sets of keys to remain connected. This
is the problem: The solution does not scale to large numbers of devices.
However, given that all the devices have to be in a single wireless cell so they
can all hear each other, maybe that is not too much of a price to pay. At least
it's secure.  | 
Sections
Archive
Syndication
