Image Processing Reference
In-Depth Information
As encrypted messages are only accepted by a receiver if the counter value used in their MAC compu-
tation is higher than the last accepted value, the implementation of the confidentiality service in SNEP
to a certain degree also provides replay protection. If for a specific request Req an even tighter time
synchronization is needed, the request can also contain a freshly generated random number N A that
will be included in the computation of the MAC of the answer message containing the response Rsp :
A
B
N A , Req
B
A
∶{
Rsp
} <
>
CK B , A , C B
RC
CBC
(
IK B , A , N A , C B ,
{
Rsp
} <
> )
CK B , A , C B
To establish a shared secret SK A , B between two sensor nodes A and B with the help of base station
BS , SNEP provides the following protocol:
A
B
N A
A
B
BS
N A
N B
A
B
RC
CBC
(
IK B , BS
N A
N B
A
B
)
BS
A
∶{
SK A , B
}
K BS , A
RC
CBC
(
IK BS , A
N A
B
∣{
SK A , B
}
)
K BS , A
BS
B
∶{
SK A , B
}
K BS , B
RC
CBC
(
IK BS , B
N B
A
∣{
SK A , B
}
)
K BS , B
In this protocol, A first sends a random number N A and his name to B ,whointurnsendsboth
values together with his own random number N B and name B to the base station. he base station
then generates a session key SK A , B and sends it to both sensor nodes in two separate messages, which
are encrypted with the respective key the base station shares with each node. he random numbers
N A and N B allow both sensor nodes to verify the freshness of the returned message and the key
contained in it.
Regarding the security properties of this protocol, however, it has to be remarked that in a strict
sense the protocol as formulated in [PST + ] does neither allow A nor B to perform concurrent key
negotiations with multiple entities, as in such a case they would not be able to securely relate the
answers to the correct protocol run (please note that the name of the peer entity is not transmitted
in the returned message but only included in the MAC computation). Furthermore, neither A nor B
knows, if the other party received the key and trusts in its suitability, which is commonly regarded
as an important objective of a key management protocol [GNY]. Finally, the base station cannot
deduce anything about the freshness of messages and can therefore not differentiate between fresh
and replayed requests for a session key.
10.4 Authenticated Broadcast
Authenticated broadcast is required if one message needs to be sent to all (or many) nodes in a sen-
sor network, and the sensor nodes have to be able to verify the authenticity of the message. Examples
for this communication pattern are authenticated query messages, routing beacon messages, or com-
mands to reprogram an entire network. Because it has to be ensured that recipients of such a message
should not be able to make use of their verifying key for forging authenticated messages, an asym-
metric mechanism has to be deployed. As pointed out before, classical asymmetric cryptography,
however, is considered to be too expensive in terms of computation, storage, and communication
requirements for sensor nodes.
Search WWH ::




Custom Search