Cryptography Reference
In-Depth Information
resource constraint environment such as WSN, adding a counter with each message
could severely increase storage and communication overhead. Hence, to avoid this
issue, the counter is shared between the sender and the receiver. Since the state of the
counter is kept at each end of the communicating party, the need for repeated transmis-
sion can be completely avoided.
SNEP uses the Cipher Block Chaining-Message Authentication Code (CBC-
MAC) scheme to construct MAC. The counter value is included during the calculation
of MAC to prevent any form of replay attacks. For instance, if A is interested in talking
to B securely, A would construct a message
{} AB
D
and
MAC
[|| {}
C
D
]
¢
, where K AB is the encryption key that is derived from the master secret X AB , which is
used to encrypt data D .
A
KC
,
K
KC
,
A
AB
AB
A
K ¢ is a MAC key that is derived from X AB . In addition, strong
freshness that includes delay estimation could be achieved by considering a nonce N
value during MAC calculations. Then, A would send the following to B:
AB
{} AB
D
and
KC
,
A
MAC N C D ¢ . Although the counter value is not being sent with the
transmitted packet, in a real environment packets could possibly be dropped during
transmission. This could lead to a synchronization problem. Protocols that would need
resynchronization would simply bootstrap the counter value. For example, A would
send the counter value C A to B. B would respond with C B and
[
||
|| {
}
]
A
A
K
KC
,
AB
AB
A
MAC
[,
C
C
]
. A
¢
K
BA
BA
would send back
MAC
[
C
||
C
]
.
¢
K
A
B
AB
5.2.1.2
TESLA
The main focus of TESLA is to provide authentication for broadcasted data.
Primarily, it adopts the delayed key disclosure mechanism proposed in TESLA (Perrig
et al. 2000). In this mechanism, the key utilized to authenticate the i th message is
disclosed during the ( i + 1)th message. The sink node randomly selects the last key
( K n ) of a chain and generates the rest of the keys ( K 0 , K 1 , K 2 , . . . , K n -1 ) in the chain as
K i = h ( k i +1 ). As a result, if a node is given K i , it is able to generate keys ( K 0 , K 1 , K 2 , . . . ,
K i -1 ). However, this node cannot generate K i +1 . Upon deployment of the sensor nodes,
the sink node sends an authenticated message
MAC D during the time slot and
the leaf nodes are required to store this message until the sink node sends the verifica-
tion key ( K i ) at the l + d th time slot. The parameter d is the delay in the disclosure.
Subsequently, the leaf nodes use the current disclosed key K i to verify the previous key:
K i -1 = h ( k i ). However, this delayed key disclosure mechanism would require the storage
of keys until the authentication key is received. This mechanism could lead to stor-
age problems, consequently leading to DoS attacks. For instance, the adversary could
flood nodes with fake keys that would exhaust the storage capacity of each node. As in
SNEP, TESLA incorporates the bootstrapping procedure to overcome the synchro-
nization problem. However, bootstrapping would demand unicast communication,
which would result in an increased volume of message flow in the network and would
result in network congestion with the increase in scalability. Consequently, the option
of multiple sender nodes broadcasting simultaneously is totally ruled out. To overcome
this problem, TESLA extensions have been proposed to address scalability issues by
including two or more key chain levels (Liu and Ning 2003).
[]
K
i
Search WWH ::




Custom Search