<<

. 67
( 87 .)



>>


12.5.1.1.2 A New Proposal. To address the shortcomings of WEP, IEEE has set up a
special Task Group I (TGi) in charge of designing the new security architecture as part of
the forthcoming version of the standard called 802.11i . To cope with brute force attacks,
TGi has already proposed to include a 128-bit RC4 seed of which 104 bits are secret. TGi
also proposed a long-term architecture based on the IEEE 802.1x standard, which itself is
based on the IETF™s Extensible Authentication Protocol (EAP). IEEE 802.1x has a flexi-
ble design supporting various authentication modes. However, the new proposal based on
802.1x already suffers from problems like lack of data integrity for wireless frames and
lack of mutual authentication.


12.5.2 Bluetooth Security Mechanisms
The Bluetooth specification [27] includes a set of security profiles defined for the appli-
cation layer in the so-called service-level security and security profiles for the data-link
layer. Both types of profiles rely on key management, authentication, and confidentiality
services based on cryptographic security mechanisms implemented in the data-link layer.
Each Bluetooth device stands for an independent party from the point of view of the secu-
rity protocols. In each device, security mechanisms use a set of basic components:

The device address (BD_ADDR): a-48 bit address defined by the IEEE that is
unique for each Bluetooth device
A 128-bit authentication key
A 128-bit symmetric data encryption key
A random number (RAND) generated by a pseudorandom or (physical) random
number generator

12.5.2.1 Key Management. Bluetooth key management services provide each de-
vice with a set of symmetric cryptographic keys required for the initialization of a secret
channel with another device, the execution of an authentication protocol, and the ex-
change of encrypted data with another device.

12.5.2.1.1 Key Hierarchy. The key hierarchy of Bluetooth includes two generic key
types:

1. The link key that is shared by two or more parties and used as a key-encrypting key
(KEK) to encrypt other keys during key exchange, or as a seed to generate other
keys
2. The encryption key that is a shared data-encryption key (DEK)

Both the link key and the encryption key are 128-bit symmetric keys. The link key can
further be qualified as an initialization key, a unit key, a combination key, or a master key.
350 AD HOC NETWORKS SECURITY


When two devices need to communicate using link-level security and have no prior en-
gagement, they establish a secure channel based on the initialization key. This channel is
then used by the communicating devices to establish a semipermanent link key that will
be used several times to assure further key exchange between the devices. The initializa-
tion key is not used beyond the first key exchange. Each communicating device generates
the initialization key using a pseudorandom number generator seeded with a secret per-
sonal identification number (PIN) entered by the user of each device and the value of
RAND exchanged between the devices. In order for two communicating devices to gener-
ate the same value for the initialization key, the same PIN value must therefore be entered
on both devices.
Based on the key generation and storage capabilities of each communicating device,
the semipermanent shared link key can either be a unit key or a combination key depend-
ing on the key generation and storage capabilities of communicating devices. The unit key
is a device specific key that is generated during the initialization of each device. Its value
changes rarely. It is generated using a pseudorandom number generator seeded with
RAND and BD_ADDR (device address). The combination key is a pairwise key comput-
ed by two communicating devices based on a device-specific key generated by each de-
vice. In order to compute a combination key, first each device generates a device specific
key based on RAND and BD_ADDR; the resulting keys are then exchanged between the
pair of devices using the secure channel encrypted with the initialization key. The combi-
nation key is then derived by each of the pair of devices based on a simple combination of
the two device-specific keys.
The type of the link key to be used on a pairwise connection between two communicat-
ing devices is negotiated during link establishment. If one of the devices has restricted
storage, then this device™s unit key is used as the pairwise link key, with obvious draw-
backs due to the widespread disclosure of a semipermanent device-specific key. If both
communicating devices have sufficient computing (key generation) and storage capabili-
ties, then they choose to use a combination key as a pairwise link key that has a different
value for each pair of entities.
In a master“slave scenario, a short-lived link key called the master key can be used be-
tween the master device and the slave devices. The lifetime of a master key is limited to
the duration of the master“slave session. The master key is generated by the master device
using a pseudorandom number generator seeded by RAND and PIN. The resulting key is
distributed through a channel secured under the initialization key to each slave the master
wants to share the master key with.
The encryption key is generated by a pair of devices that share a link key using a
pseudorandom number generator seeded by the link key, the random number RAND gen-
erated by one of the devices and transmitted to the other device prior to encrypted data ex-
change, and the secret Authenticated Ciphering Offset (ACO) generated by each device
during the authentication process.

12.5.2.2 Authentication. The Bluetooth authentication scheme is based on a chal-
lenge“response protocol as depicted in Figure 12.2. When device A wants to authenticate
device B using this protocol, A generates a random number (RAND) and sends it to B as a
challenge, then both devices compute a result (SRES) using the authentication algorithm
E1 with RAND, the link key, and the device address of B. B then sends A a SRES as the
response to A™s challenge RAND. B is successfully authenticated if the resulting SRES
computed by A matches its SRES. During authentication, each device also obtains the Au-
351
12.5 SECURITY MECHANISMS IN LAYER




Figure 12.2. Authentication of Device B by Device A.



thenticated Ciphering Offset (ACO) generated by the authentication algorithm E1. The
ACO value is further used to generate the data-encryption key that will be used between
the pair of devices.

12.5.2.2.1 Data Encryption. Bluetooth devices can perform data encryption using a
stream cipher based on Linear Feedback Shift Registers (LFSR). The stream cipher gener-
ates a key stream that is used by the sender to encrypt the payload field of each packet us-
ing the one-time pad technique (the ciphertext is obtained as a result of the bit-wise exclu-
sive-or operation performed on the payload and the key stream). The recipient of the
packets decrypts the encrypted payload field of each packet by generating the key stream
and combining it with the encrypted payload fields based on the one-time technique. The
stream cipher is initialized by both communicating devices with the device address of the
master device, the value of the shared encryption key, and the clock of the master device.
The stream cipher is resynchronized for each payload using the master™s clock. A new key
stream is thus generated to encrypt each payload.

12.5.2.2.2 Security Evaluation. The Bluetooth security architecture suffers from
some weaknesses in the key management scheme. The main concern is the weakness of
the key-generation process for the initialization key. The initialization key is derived
from a random number and a secret PIN, whereby the only secret is the PIN. Due to lim-
ited capability of human memory, the PIN typically is chosen as a number with at most
six digits. A six-digit secret can easily be retrieved by exhaustive search. Another expo-
sure exists when a device™s unit key is used as the link key. If a device™s unit key is used
as the link key for the purpose of parallel or subsequent communications between this
device and several other devices, the secret unit key of the device is disseminated to sev-
eral devices that might include potential intruders. Various types of attacks ranging from
the impersonation of the legitimate owner of the unit key to the decryption of encrypt-
ed traffic by intruders become feasible based on the knowledge of a device™s unit key by
intruders.
352 AD HOC NETWORKS SECURITY


12.5.3 Relevance of Security Mechanisms in the Data-Link Layer
Although the relevance of security mechanisms implemented in the data link layer is often
argued, this question deserves careful analysis in the light of requirements raised by the
two different environments in which these mechanisms can be deployed:

1. Wireless extension of a wired infrastructure as the original target of 802.11 and
Bluetooth security mechanisms
2. Wireless ad hoc networks with no infrastructure

In (1), the main requirement for data-link-layer security mechanisms is the need to cope
with the lack of physical security on the wireless segments of the communication infra-
structure. Data-link-layer security is then perfectly justified as a means of building a
“wired equivalent” security as stated by the objectives of WEP. Data-link-layer mecha-
nisms like the ones provided by 802.11 and Bluetooth basically serve as access control
and privacy enhancements to cope with the vulnerabilities of radio communication links.
However, data-link-layer security performed at each hop cannot meet the end-to-end secu-
rity requirements of applications either on wireless links protected by 802.11 or Bluetooth
nor on physically protected wired links.
In case of wireless ad hoc networks as defined in (2), there are two possible scenarios:

Managed environments whereby the nodes of the ad hoc network are controlled by
an organization and can thus be trusted based on authentication
Open environments with no a priori organization among network nodes

The managed environment raises requirements similar to ones of (1). Data-link-layer
security is justified in this case by the need to establish a trusted infrastructure based on
logical security means. If the integrity of higher-layer functions implemented by the nodes
of a managed environment can be assured (i.e., using tamperproof hardware) then data-
link-layer security can even cover higher-level security requirements raised by the routing
protocol or the applications.
Open environments, on the other hand, offer no trust among the nodes and across com-
munication layers. In this case, trust in higher layers like routing or application protocols
cannot be based on data-link-layer security mechanisms. The only relevant use of the latter
appears to be ad hoc routing security proposals whereby the data-link-layer security can
provide node-to-node authentication and data integrity as required by the routing layer.
Moreover, the main impediment to the deployment of existing data-link-layer-security so-
lutions (802.11 and Bluetooth) would be the lack of support for automated key manage-
ment that is mandatory in open environments where manual key installation is not suitable.


12.6 CONCLUSION

The need for security mechanisms that cope with the threats that are specific to the ad hoc
environment has recently gained attention among the research community. In order to
avoid the same problems that arose in wired networks like the Internet, security has to be
taken into account at the early stages of the design of basic networking mechanisms like
the data-link layer and the network-layer protocols. Since the correct network operation
353
REFERENCES


can be heavily jeopardized by threats that range from simple lack of cooperation to rout-
ing message modification, ad hoc networks without a proper defense against attacks that
are specific to this new networking paradigm cannot exist.
Current efforts carried out by the research community in order to support ad hoc net-
works with practical security mechanisms have to cope with a challenging environment,
where limitations on battery life, computational power, and storage resources, not to men-
tion the lack of any fixed infrastructure, make the design of a security infrastructure very
difficult.
The security mechanisms presented in this chapter are a practical response to specific
problems that arise at a particular layer of the network stack. However, the proposed solu-
tions only cover a subset of all possible threats and are difficult to integrate with each oth-
er. As an example, the secure routing protocols analyzed in this chapter do not cope with
the lack of cooperation of the nodes of the network, and are not designed to incorporate a
cooperation enforcement mechanism. An exhaustive security infrastructure has to consid-
er a wide range of attacks and has to be made of easy-to-integrate components. Further-
more, security needs may vary according to different networking scenarios and the securi-
ty mechanisms adopted to combat misbehaving or compromised nodes have to be flexible
enough to be used in different environments. The direction that has been taken by the re-
search community in order to support ad hoc networks with security mechanisms con-
firms this vision, and the proposed solutions are gradually reaching a mature stage, mak-
ing ad hoc networking a realistic alternative to wireless and 3G networks.


REFERENCES

1. P. Papadimitratos and Z. Haas, “Secure Routing for Mobile Ad Hoc Networks,” in Proceedings
of CNDS 2002.
2. Y-C Hu, A. Perrig and D. B. Johnson, “Ariadne: A secure On-Demand Routing Protocol for Ad
Hoc Networks,” in Proceedings of MOBICOM 2002.
3. A. Perrig, R. Canetti, D. Song, and J. D. Tygar, “Efficient and Secure Source Authentication for
Multicast,” in Proceedings of NDSS 2001.
4. A. Perrig, R. Canetti, J. D. Tygar, and D. Song, “Efficient Authentication and Signing of Multi-
cast Streams over Lossy Channels,” in Proceedings of IEEE Symposium on Security and Priva-
cy, 2000.
5. B. Dahill, B. N. Levine, E. Royer, and C. Shields, “ARAN: A secure Routing Protocol for Ad
Hoc Networks,” UMass Tech Report 02-32, 2002.
6. Y-C Hu, D. B. Johnson, and A. Perrig, “SEAD: Secure Efficient Distance Vector Routing for
Mobile Wireless Ad Hoc Networks,” in Proceedings of 4th IEEE Workshop on Mobile Comput-
ing Systems and Applications.
7. C. E. Perkins and P. Bhagwat, “Highly Dynamic Destination-Sequenced Distance-Vector Rout-
ing (DSDV) for Mobile Computers,” in Proceedings of SIGCOMM 1994.
8. J. Broch, D. A. Maltz, D. B. Johnson, Y-C Hu, and J. G. Jetcheva, “A Performance Comparison of
Multi-Hop Wireless Ad Hoc Network Routing Protocols,” in Proceedings of MOBICOM 1998.
9. P. Johansson, T. Larsson, N. Hedman, B. Mielczarek, and M. Degermark, “Scenario-based Per-
formance Analysis of Routing Protocols for Mobile Ad Hoc Networks,” in Proceedings of
MOBICOM 1999.
10. A. Perrig, Y-C Hu, and D. B. Johnson, “Wormhole Protection in Wireless Ad Hoc Networks,”
Technical Report TR01-384, Dept. of Computer Science, Rice University.
354 AD HOC NETWORKS SECURITY


11. P. Michiardi and R. Molva, “Simulation-based Analysis of Security Exposures in Mobile Ad
Hoc Networks,” in Proceedings of European Wireless Conference, 2002.
12. D. B. Johnson and D. A. Maltz, “Dynamic Source Routing,” in Ad Hoc Wireless Networks, Mo-
bile Computing, T. Imielinski and H. Korth (Eds.), Chapter 5, pp. 153“181, Kluwer Academic
Publishers, 1996.
13. C. Perkins, “Ad hoc On Demand Distance Vector (AODV) Routing,” Internet draft, draft-ietf-
manet-aodv-00.txt.
14. L. Buttyan and J.-P. Hubaux, “Nuglets: A Virtual Currency to Stimulate Cooperation in Self-
Organized Ad Hoc Networks,” Technical Report DSC/2001/001, Swiss Federal Institute of
Technology, Lausanne, 2001.
15. S. Buchegger and J.-Y. Le Boudec, “Nodes Bearing Grudges: Towards Routing Security, Fair-
ness, and Robustness in Mobile Ad Hoc Networks,” in Proceedings of the 10th Euromicro Work-
shop on Parallel, Distributed and Network-based Processing.
16. S. Buchegger and J.-Y. Le Boudec, “Performance Analysis of the CONFIDANT Protocol,” in
Proceedings of MobiHoc 2002.
17. S. Marti, T. Giuli, K. Lai, and M. Baker, “Mitigating Routing Misbehavior in Mobile Ad Hoc
Networks,” in Proceedings of MOBICOM 2000.
18. P. Michiardi and R. Molva, “Core: A COllaborative REputation mechanism to Enforce Node
Cooperation in Mobile Ad Hoc Networks,” in Proceedings of IFIP Communication and Multi-
media Security Conference 2002.
19. P. Michiardi and R. Molva, “Game Theoretic Analysis of Security in Mobile Ad Hoc Net-
works,” Institut Eurecom Research Report RR-02-070, April 2002.
20. H. Yang, X. Meng, and S. Lu, “Self-Organized Network-Layer Security in Mobile Ad Hoc Net-
works.”
21. S. Capkun, L. Buttyan, and J-P Hubaux, “Self-Organized Public-Key Management for Mobile
Ad Hoc Networks,” in Proceedings of ACM International Workshop on Wireless Security, WiSe
2002.
22. P. Zimmermann, The Official PGP User™s Guide, MIT Press, 1995.
23. M. Reiter and S. Stybblebine, “Authentication Metric Analysis and Design,” ACM Transactions
on Information and System Security, 1999.
24. H. Luo and S. Lu, “Ubiquitous and Robust Authentication Services for Ad Hoc Wireless Net-
works,” UCLA-CSD-TR-200030.
25. A. Shamir, “How to Share a Secret,” Communications of ACM, 1979.

<<

. 67
( 87 .)



>>