by the Gateway Nodes to construct the right inter-Cluster tunnels and the correct routing over these tunnels. Another option might be to use similar information from the addressing scheme, if available.
4.4
Personal Node Authentication
After a new Node is discovered with one of the techniques mentioned in the previous section, the next question is whether this new Node is a Personal Node or not. This is where the pair-wise keys established during the im- printing procedure come in. Every pair of Personal Nodes shares a Trust Relationship, which means that they have a common pair-wise key, which both Nodes store in their local memory. A cryptographic procedure using the pair-wise keys can determine whether a newly discovered neighbor Node is a Personal Node or not. Figure 4.3 shows a schematic view of the decision process each Node must follow. There are three possible outcomes for each newly discovered neighbor Node:
Personal Node The new Node can successfully authenticate as a Personal Node with the pair-wise key. The new Node is then added to the list of neighboring Personal Nodes and a secure connection using the pair- wise key is established as described earlier. Note that this should be mutual.
Imprinting Node The new Node is being imprinted or wants to be im- printed, i.e., the Node is in the process of being personalized. Exactly which steps will take place here is further defined in Section 3 in [138]. The Node is considered Foreign until the personalization is completed. Foreign Node This means that the new Node is not a Personal Node or
failed to authenticate as a Personal Node.
4.4.1
Neighbor Node authentication
When a new Node is discovered, it can send a message in the clear that claims its association with a certain PN using any unique identifier associ- ated with that PN. A Node that receives such a claim can use that identifier in combination with a unique Personal Node identifier or address to select the correct pair-wise key if it has one. The receiving Node challenges the new neighbor by sending a message with a random number encrypted us- ing the matching pair-wise key. If the new Node can decipher it and send back a different message that includes the same random number and again encrypted using the same pair-wise key, then the neighbor is assumed to be authenticated as a Personal Node. Note that this is a very brief explanation of how a simple neighbor node authentication protocol could work. An actual
Figure 4.3: The decision procedure for Personal Node detection
implementation needs to include more features in order to fully protect the system against all known attacks.
For this or any other similar schemes to work, it is necessary for the Nodes to transmit their identifiers. This includes both a PN identifier and a Node identifier so that a receiving Node knows exactly which pair-wise key to use. The identifier can be a MAC address, the PN-local IP address or anything else that is fixed. One solution is for each Personal Node to have a mapping between MAC addresses and the pair-wise key for every other Personal Node.
4.4.2
Anonymity
For privacy reasons, it is not always wise to expose fixed and unique identities. Frequently transmitted identities, such as PN and Node identifiers, can be linked to the user of that device and this makes the device and its user no longer anonymous. This also includes fixed network addresses. A mobile device is said to be anonymous if it does not reveal anything that can be used to link it to a person or to a previously encountered device. The latter means that it is impossible for someone to know whether he/she has communicated with or overheard communication from the same device before or not.
When packets with fixed addresses are sent back and forth, it is possible for any third party to know who communicates with whom and at what time. Further, protocol analysis can quite accurately guess what type of data is being sent (e.g., voice, email, or web) even if the traffic is encrypted. For mobile devices, the addresses may also tell something about the location
4.4. PERSONAL NODE AUTHENTICATION 69
of that device at the time of communication. When all this is put together from many sources, a lot of information can be deduced that may reveal a person’s location, who he is communicating with, and at what time— potentially information the person does not want to reveal. Furthermore, anyone can lay their hands on this information, not just network providers.
All this is actually no longer just theoretical threats; a system to track Bluetooth devices was installed in September 2007 in Apeldoorn in the Neth- erlands [23]. Currently, the system consists of 5 stations at different locations recording anyone passing by with a device with Bluetooth switched on. If you know someone’s Bluetooth MAC address, you can detect when and if that device has been seen on any of the locations through a website [23].
Hence, it is necessary to hide such identities to remain anonymous. Un- fortunately, that also makes it harder for the Nodes to select the correct pair-wise key when encountering new neighbors. In the worst case, all stored pair-wise keys must be tested one by one before the authentication fails and the Node is declared Foreign. This is, of course, a waste of communication and computational resources and better solutions are needed.
One very simple idea, we propose in lack of better options, is to have one PN-wide key that is shared by all Nodes in a PN. The key can be exchanged during the personalization so that every Node in the PN can store it in its local memory. The key should only be used to encrypt PN and Node identities and nothing else. Then, breaking of this key only leads to lost anonymity, but not to access to the PN network. The latter still requires breaking the pair-wise key.
While it is possible to encrypt all fixed addresses and identifiers in the network layers and higher, it is also necessary to protect fixed addresses used by the lower layers. Most wireless technologies use unique identifiers that can be read and used in clear and it is simply not possible to encrypt them, since they are used to determine the sender and the receiver. WLAN (IEEE 802.11) is one example. Each WLAN card has a hardware address of six bytes that is used when communicating with another WLAN-equipped device or access point. To make sure that addresses never clash, each WLAN card is equipped with a globally unique address. This address can, of course, be used to map to the owner of the laptop it belongs to. Furthermore, the WLAN card is constantly transmitting its hardware address in clear, even when encryption is used. This is still the case when using the latest WLAN encryption standards, such as Wireless Protect Access (WPA) and WPA2 [83]. Also Bluetooth suffers from the same problem since it uses the same type of hardware addresses. However, Bluetooth is slightly better as it does not transmit its unique hardware address with every message. It is only sent as part of the piconet formation procedure after discovering a new neighboring device.
The best answer to this problem is to get rid of the uniqueness and fre- quently change link layer addresses, since global uniqueness is not really
needed anyway. The address only needs to be unique among the devices in the close vicinity, where its transmissions can be received. Even if there are address conflicts, they can be solved by inspecting the (encrypted) network layer address or by the failure to decrypt the packets. A conflict only de- grade the performance somewhat. The addresses can easily be manipulated anyway and hence cannot offer any additional security.
We should also note that just as there is no perfect security, perfect anonymity is impossible. There will always be information leakage that may be used to guess who the user of a device is. However, this must not stop us from developing techniques that make this more difficult. Instead, the most obvious vulnerabilities must be avoided which will make it much harder for an adversary to discover this kind of information. The first step is to avoid fixed addresses that are sent unencrypted and can be overheard by non- authorized peers. When that is taken care of, an attacker needs to turn to the physical layer to look for clues. One example is using a technique called radio frequency fingerprinting (RFF) [70]. However, techniques like this one are also much more difficult than just listening for unencrypted fixed identifiers.