3.3 Problem Definition
3.3.2 Problems with the Establishment of Different Types of Keys
As discussed in Chapter 2, LEAP [29] supports the establishment of individual keys, pairwise keys, cluster keys, and a global key. Individual key which is a unique key shared between the base station and each sensor node [29]. The key is pre-calculated and preloaded into each node’s memory before being deployed. A pairwise key is shared between each pair of neighboring nodes. Each node U is preloaded with a key Ki. U drives the master key Ku using it. Correspondingly, a neighboring node V can derive its master key Kv too. The node U computes the pairwise key
Kuv = fKv(u). Node V can also compute Kuv in the same way. Cluster keys
are built upon the pairwise keys. A node U encrypts the selected cluster key Kc u with the pairwise keys of its neighboring nodes and sends the encrypted key to each neighboring node. The global key originates from the base station and recursively transits to all the nodes in a width priority manner. The time-based key management scheme [1] uses different initial keys for pairwise key establishment at different time slots. The establishment of other types of keys is the same as that in [29].
Technical problems
We cannot deny that LEAP presents an efficient way of establishing different types of keys. However, this scheme cannot be used in WSNs which have strict secu- rity requirements. This is because current schemes LEAP [29] and the time-based scheme [1] have the following technical issues:
• LEAP suffers from sinkhole attack. In a sinkhole attack, a compromised node attracts packets by advertising information such as high battery power, etc., then later drops all the packets [41].
• The initial key is reused again for node addition in LEAP. The initial key which is removed after the initialization phase is reused. However the new node could be captured before erasing the initial key. Various attacks can be launched based on the disclosed initial key.
• In scheme [1], the key connectivity is reduced even though the threat caused by the disclosure of the initial key is eliminated. The key connectivity is af-
Figure 3.2: Plain SNEP protocol which offers weak freshness
fected by the number of preloaded master keys m and the order of the current time slot. A higher key connectivity can be achieved at the cost of heavy burden on storage.
• In scheme [1], the established pairwise key does not exclusively belong to the two end nodes. As we discussed in Chapter 2, nodes in one time slot may have knowledge of the pairwise keys established by nodes in other time slots. This drawback makes the scheme vulnerable to attacks against confidentiality and authentication.
• In scheme [1], some of preloaded master keys are useless. m randomly- chosen master keys are preloaded to the memory of each node before it is deployed to the network without consideration of lifetime of the node. Some preloaded master keys are unused because a node’s lifetime is limited.
3.3.3 Problems with Authentication Mechanisms in Key Man-
agement
Existing solutions
Authentication is an important tool which is used to verify the transferred messages and communication counterparts. We have examined current research on authenti- cation in wireless sensor networks: unicast authentication, broadcast authentication, filtering false data, PKC-based authentication, and lightweight authentication.
Figure 3.3: Strong SNEP protocol which offers strong freshness
Figure 3.4: TinySec packet formats in TinySec-Auth mode and TinySec-AE mode
shown in Figure3.2 and Figure3.3, plain SNEP offers weak freshness and strong SNEP offers strong freshness. In Figure3.2, KAB and KBAare encryption keys and for directional communication between node A and node B, respectively; K0
ABand
K0
BA are authentication keys and for directional communication between node A and node B, respectively; CAand CBare counters maintained by node A and node
B, respectively; M1 is the message transferred from node A to node B and M2 is
the message transferred from node B to node A. In Figure 3.3, node A generates a nonce NA and sends it along with a request message RA to node B. Then B returns the nonce with the encrypted response message RB, along with the MAC of encrypted message RB, CB, and NA. If the MAC verifies correctly, node A knows that node B generated the response after it sent the request [111].
TinySec provides two different packet formats: TinySec-Auth for authentica- tion only and TinySec-AE for authentication and encryption. The two packet for- mats are shown in Figure 3.4. In TinySec-Auth mode, the un-encrypted packet is
Figure 3.5: µTESLA one-way key chain [2].
authenticated with a MAC. In TinySec-AE mode, packet is encrypted first and then authenticated with a MAC.
µTESLA provides authentication for broadcast with a one-way key chain of
authentication keys. Figure3.5displays the evolution of authentication keys. K0 is
the initial key.
MAC is the basic way used of filtering false data. Both SEF [75] and hop- by-hop authentication can be seen as variants of MAC. PKC-based authentication has incomparable advantage than symmetric key based authentication. Existing PKC-based authentication for WSN [77] cannot be seen as purely PKC-based au- thentication. The notion of “lightweight authentication” comes from authentication for RFID. Even though it was claimed as a “lightweight” mechanism, it has high computation and communication overhead.
Technical problems
• The feasibility of SNEP has not been fully specified and implemented. Tiny- Sec does not provide replay protection for the message, which is an important security requirement. It does not renew the key over time. TinySec requires extra energy, bandwidth, and incurs latency overhead with increased packet length [111].
• All µTESLA-based broadcast authentication schemes [2,28, 29,30] require loosely time synchronization. A delayed packet authentication mechanism may suffer from severe energy-depletion DoS attacks.
• It is not known how to keep the trade-off between the shared secrets between nodes and the probability of SEF [75]. The three hop-by-hop authentication schemes in [76] can only be applied to data collection rather than hop-by-hop data aggregation applications.
• To date, no feasible lightweight authentication and PKC-based authentication schemes have been proposed for WSNs.
• No unified standard can be used to evaluate whether a scheme is lightweight or not.