Comparación equitativa entre valor normal y precio de exportación

6.4

Discussion of the new Protocol

After an overview of the functionality of our new protocol SecSyWiSe, we will now discuss how it can be implemented and how it achieves the desired security and privacy goals.

6.4.1 Using Cryptographic Primitives

When using asymmetric signatures, an attacker that can read a receiving node’s internal data cannot impersonate the source node. An attacker that is able to physically modify a receiving node cannot achieve more than to convince this single node that messages sent by himself are legitimate.

Messages sent by the source node are authenticated by the use of digital signatures. Therefore, the nodes must be able to perform asymmetric signature verification. As the source node must transmit all synchronization messages, the hardware of the source node may be designed to be more powerful than regular nodes, e.g., it may have additional batteries and/or a more powerful CPU, or a power supply connected to the electrical grid.

The asymmetric keysize must be chosen sufficiently large such that an attacker cannot obtain the private signature key, but small enough so that the signature handling is feasible on the sensor hardware. The actual keysize is left to the appli- cation developer and depends on the selection of sensor hardware and the security and lifetime requirements. The NIST considers 2048 bit for RSA and 224 bit for ECDSA sufficiently secure through 2030. [26].

In our solution, only a single key must be stored on the individual nodes, which is the public key of the source node. Storing a single public key is feasible because only a single 2048 bit RSA modulus and a public exponent has to be stored. Usually, a short verification key will be used, which can be as small as 17 bit without harming security [37], i.e., 216+ 1 = 65537. Typical sensor nodes offer between 128 kB (MICA) and 1 MB (TelosB) flash memory.

The public key must be stored in the clients before deploying them. This can be done when first installing the software on the sensor nodes by the deployer. If the private key is not compromised, there is no need to ever change the public key on the sensor nodes. If the source node fails and has to be exchanged, the new source node must use the same private key as the old source node used before.

6.4.2 Security Properties

In this section we examine how our protocol prevents certain attacks and how the security goals described in Section 6.3 are met.

Sec-1: The source node calculates a digital signature on the next timestamp and

counter value that will be sent to the other nodes. An attacker cannot create a valid signature as he does not have access to the private signature key. There are

174 Chapter 6. Time Synchronization on Wireless Sensor Nodes

some attacks on authentication that are specialized on the wireless networks. We will show that none of them defeat our protocol:

Our protocol is not vulnerable to a man-in-the-middle-attack, as the signature veri- fication will fail on the receiver’s side when the message contents has been changed. Also, a man-in-the-middle-attack will be more difficult to implement against our pro- tocol compared to other protocols in practice, as the nodes do not actively forward any information.

The wormhole attack does not apply to our protocol, as all the messages are sent directly in broadcast and will not be routed at all.

Sec-2: In the proposed protocol, no secret information can be extracted from the

individual nodes, thus a node capture attack does not help the attacker to create messages that will be accepted by other nodes. Also, individual nodes are not required for a successful protocol run of any other node. Nodes trying to impersonate the source node cannot create correct message signatures, so even a single remaining node will be able to synchronize to the source node. Thus, our protocol is secure against node capture as long as the source node remains uncompromised, which is a requirement.

Sec-3: The counter in the protocol provides protection against an attacker replaying

old messages from previous synchronization runs (i.e., setting the clock back). If the node has already received a newer message, it will not accept old messages. This holds regardless of the message contents, i.e., also for non-continuous time formats. An attacker that is able to block the radio reception of a sensor node over a sufficient period of time would be able to make the sensor node accept old messages sent by the legitimate source node after the start of the radio blocking in a pulse delay attack as shown in Figure 6.2. In applications that use a continuous time format, the use of filters on the nodes can provide some protection against pulse delay attacks. As filters are a countermeasure that is based on timing precision itself they must be handled with care, i.e., the threshold should be determined after a thorough evalua- tion of the clock offsets experienced on the device under similar conditions without the presence of an attacker before the nodes are deployed in a hostile environment. Also, the filter has to be deactivated for the first synchronization of a client, i.e., when its internal counter is zero.

In applications that use a continuous time format, the use of filters on the nodes can provide some protection against pulse delay attacks. As filters are a countermeasure that is based on timing precision itself they must be handled with care, i.e., the threshold should be determined after a thorough evaluation of the clock offsets ex- perienced on the device under similar conditions without the presence of an attacker before the nodes are deployed in a hostile environment. Also, the filter has to be deactivated for the first synchronization of a client, i.e., when its internal counter is zero.

Pri-1: Not requiring the receiving nodes to transmit any messages for our protocol

facilitates undetectability: An attacker is unable to detect the nodes, and thus the attacker cannot count or locate the nodes.