Analysis

6.5. ANALYSIS 101

smart card and offers high security mechanisms for preventing unauthorized extraction of protected keys. This makes it extremely difficult for an adversary to retrieve the necessary keys to decrypt the sealed hash chain. Additionally, access to the sealed hash chain is only possible if the platform configuration has not been modified. This prevents the unauthorized extraction of the values of the hash chain in a compromised system environment. Even if an adversary could access the RAM of a sensor node, he cannot retrieve other hash values, because for each attestation only the current hash value is unsealed and loaded into the RAM.

However, our approach cannot handle runtime attacks caused by buffer overflows, since we report the platform configuration measured in the initialization phase, i.e., when the software is first executed. Such attacks would result in a (malicious) modified system configuration, but the platform configuration stored in the PCRs is still the valid configuration.

If the attestation is performed between nodes which are multiple hops away, an adversary might also try to perform a man-in-the middle attack by compromising an en-route CN. The adversary can try to spoof, alter or replay attestation messages, or perform a selective forwarding attack [90]. Spoofing is not possible, because PBAP is not an authentication protocol. It gives an assertion about the trust level of the spe-cific SN and not which node has relayed the message. Altering attestation messages is possible and results in an unsuccessful attestation. To cope with that, a CN should possess an additional mechanism which enables the CN to reach its SN using a different communication path or change to a different SN. The CN can then use an alternative path and perform the IAP with the SN to make a clear statement, whether the route, or the node has been compromised. If the SN is compromised, a CN could, for exam-ple, switch to another SN where the communication paths and the new SN may not have been compromised. Replay attacks or an attack where an adversary first blocks the forwarding of legitimate hash values to collect them, then compromises a SN and finally releases these hash values are not possible, because hash values are only valid for a specific interval, which is validated by each CN. Since the PBAP is performed in plaintext an adversary can distinguish between attestation and data messages and therefore perform a selective forwarding attack by forwarding attestation messages, but blocking data messages. Such attacks are a general problem in WSNs and show that the PBAP is not resistant against all attacks in a multihop scenario with malicious en-route CNs.

Security of the IAP

The security of the IAP relies on the sealing of the symmetric keys to the valid platform configuration analogue to the sealing of the hash chain described above. Thus, an adversary compromising a SN cannot access the necessary keys to perform a successful attestation.

If the attestation messages are forwarded along multiple hops, an adversary can try to perform a man-in-the-middle attack. Since the IAP includes an authentication protocol, spoofing is not possible. A SN detects the modification of the first attestation

6.5. ANALYSIS 103 message (see Protocol 6.4.4) by an en-route adversary, since the included identifier does not match the identifier sent in plaintext. If the adversary alters the response sent to a CN, the latter cannot distinguish if either the attestation has failed or if the message has been altered by the adversary. Replay attacks are not possible, because a new nonce is used in each message. Since attestation messages and data messages have the same form (identifier plus encrypted data block), an adversary cannot distinguish between them to perform a sophisticated selective forwarding attack. If the modified IAP is used, where data is sent in the first step, an adversary might be able to distinguish between this message and the response message (step 6) because of the different lengths of the messages. To cope with that, the message sent in step 6 could be padded to the same length.

Thus, if an attestation fails, a CN should first try to perform a new attestation of the same SN using another communication path, if possible. If this is not possible or the attestation fails again, either the SN or a node on the communication path is compromised. The CN should then select a new SN, since messages sent to the old one might be susceptible to attacks.

Furthermore, in contrast to scenarios where SNs are not equipped with a TPM, a single compromise of a SN does not result in the compromise of all shared keys stored on this node. Even using the TPM in only a few nodes results in a higher resiliency to node compromise.

6.5.2 Performance Analysis

Efficiency is crucial for security protocols for WSNs as well as embedded systems because of the limited resources of nodes. Protocols should not introduce a high storage overhead and should not significantly increase energy consumption. Since we assume that SNs possess sufficient resources, we perform our analysis only for the CNs. We restrict us to only perform an analysis for the WSN scenario, since these devices typically possess lower computation power and lesser power supply. For this purpose, we first analyze the additional storage requirements. Next, we estimate the additional energy consumption by evaluating the computational and communication overhead.

Storage Requirements

For the PBAP, a CN must store one hash value and the identifier for the corresponding SN. Depending on the network configuration, it might also store hash values (and identi-fiers) for other SNs in its vicinity. LetL_N, andL_H denote the length of anode identifier and a hash value respectively. Let the number of SNs for which a CN stores values be v. Thus, the storage requirementsSR_{P BAP} for a CN are:

SR_{P BAP} =v∗(L_N +L_H). (6.1)

For example, suppose a CN stores values for 5 SNs. The length of each hash value is 64 bits and the length of a node identifier is 10 bits. This results in a total of 46.25 bytes.

For the IAP, a CN must store one symmetric key for each SN with which it wants to perform an attestation. Let this number be denoted by w and the length of a key denoted by L_K. Thus, the storage requirementsSR_IAP for a CN are:

SR_IAP =w∗L_K. (6.2)

For example, suppose a CN stores keys for 5 SNs. The length of each key is 64 bits.

This results in a total of 40 bytes.

The Berkeley Mica2 Mote [41] offers 4KB of SRAM. As a result, a CN of type Berkeley Mica2 Mote can store 512 keys, giving him the ability of performing the IAP with 512 different SNs. In case of the PBAP, he can store approx. 443 hash values, thus, a CN is able to attest 443 different SNs using the PBAP. Therefore, the storage requirements are suitable for current sensor nodes, even if both protocols are used in conjunction.

Energy Consumption

The PBAP requires a CN to receive one attestation message and to perform one hash computation at each time interval. An attestation message consists of a hash value and an identifier of the interval, e.g., a counter. Although computing hash values only marginally increases energy consumption [119], we consider the computational overhead, since a hash computation is performed in each time interval.

We use e₁ = e_1s +e_1r to denote the energy consumed in sending and receiving one byte, and e2 to denote the energy for one hash computation. In addition to the notation used above, let L_T denote the length needed for the interval identifier. The total number of intervals in the whole lifetime of the network is denoted with t. This results in an additional energy consumption:

E_{P BAP} =t∗((L_T +L_H)∗e1r+e2). (6.3) For example, suppose the lifetime of the network is one year and broadcast messages are sent every 10 minutes. Therefore, a 16 bit counter is sufficient for numbering each interval. We use the results presented in [190] to quantify e_1s= 16.25 µJ for sending, e1r = 12.5µJ for receiving, ande1 = 28.75µJ for sending and receiving one byte using Berkeley Mica2 Motes. The energy consumed for performing one hash computation using RC5 [127] block cipher ise₂= 15 µJ. This results in a total energy consumption of 7358.4 mJ. The Mica2 Motes are powered with two 1.5 V AA batteries in series connection. We assume a total capacity of 2750 mAh using standard AA batteries which results in 29700J. Thus, the ratio of energy consumed in one year by the PBAP is about 0.025% of the total available energy which is negligibly small.

The IAP requires a CN to generate and send a challenge², and the verification of the response (see Protocol 6.4.4, steps 1, 6, 8 and 9). The challenge requires one nonce generation, one encryption and one transmission, while the response verification

2We do not consider the case where data is sent within the challenge, because we estimate only the additional overhead introduced by our protocol.

6.6. IMPLEMENTATION 105