Message Integrity and Authenticity

The length of MAC is 8 or 16 bytes in most of the today’s protocols. The security of a k-bit MAC is identified by comparing to a random selected function from the set of all functions. For example if CBC-MAC is used as a random function with 4 bytes of output, then an attacker has probability of 1/232 for finding a valid MAC for a particular message.

It is stated that for a network using TinySec finding a valid MAC with a 19.2 Kb/s channel (40 packets per second) requires over 3 years for an attacker. It is also easy to detect when such an attack is happening where nodes can warn the base station when the rate of MAC failures exceeds some predetermined value [19].

10.5.2 Confidentiality

The main property of IVs is to be unique, but using an 8 byte counter or 16 byte random value makes the IV easily repeatable. TinySec uses an 8 byte IV where the first 4 bytes are generated from the destination address, the AM type, and the length. The other 4 bytes of the IV are generated from src which is the source address of the sender and ctr which is a 16 bit counter starting at 0 (Figure 10.7).

The algorithm selected CBC mode because of its robustness to information leakage when IVs repeat. It is proposed that in stream ciphers a repeated IV can reveal the plaintext of both messages, but in CBC mode IV reuse reveals only the length of the longest shared prefix of the two messages. It is obvious that the dest||AM||l which forms the first 4 bytes of the IV help to prevent information leakage when the counter repeats on a node except for the dest||AM||l values to be exactly the same for both messages.

Information leakage only occurs if a node sends two different packets with the same first 8 bytes and IV, to the same destination, with the same AM type, and of the same length.

10.6 Implementation

TinySec is implemented for the Berkeley sensor network motes on TinyOS and it is an open source project within the TinyOS mainline supporting the Mica, Mica2, and Mica2Dot platforms. The Mica mote uses the RFM TR1000 radio, the Mica2 and Mica2Dot motes use the Chipcon CC1000 radio, but it is easily portable to both new processors and new radio architectures.

TinySec has 3000 lines of nesC code which creates an overhead of 728 more bytes of RAM and 7146 bytes more program space on an application using TinySec’s first implementation. Also the static lookup table of the Skipjack algorithm can be in RAM or program space which makes the algorithm 10% slower and as the motes have available RAM, the static table is stored in RAM.

―For the current TinySec release, it is optimized to use 256 bytes of RAM and 8152

bytes of ROM. The optimizations save 472 bytes of RAM at the expense of 6% slower block cipher operations‖ [19].

TinyOS radio stack is changed to create TinySec and a new secure radio component is developed for the supported platforms. For example instead of using TinyOS default radio component, TinySec’s secure radio component is tied to the application. This is supplied by setting the ―TINYSEC‖ parameter in the makefile of your application to true. TinyOS build scripts fetch the correct components for the TinySec and use them (see Figure 10.8).

Figure 10.8: TinySec and TinyOS interfaces [20].

The TinySec protection level is stored in the upper two bits of the length byte because the maximum data payload is 32 bytes (TinySec AE, TinySec Auth, or normal TinyOS packets).

For the development of TinySec, TinyOS scheduler is changed to complete cryptographic computations on time. When the radio channel is acquired TinySecM module is started and the cryptographic computations are done.

This process must be completed by the time the radio finishes sending the start symbol. ―The TinyOS scheduling process which runs tasks in FIFO order is modified

to include two priority schedulers, where cryptographic operations are run with high priority where the computations are performed as the radio stack receives enough data‖ [19].

Another valuable property of TinySec is it is cipher independent and it can use Skipjack with the current implementation. Other algorithms can also be adopted to be used by TinySec easily.

10.7 Measurements

TinySec Secure

Radio Component

(TINYSEC=true)

App

Radio

Normal

Radio Component

(TINYSEC=false)

App

Radio

packet lengths where TinySec increases packet lengths by 1 or 5 bytes for TinySec Auth or TinySec AE usage respectively.

It is stated that some tests have been done by using TinySec-AE and it is seen that the packet latencies are increased by 8.0% (compared to the current TinyOS stack) and the tests that are done by using TinySec-Auth has shown that it causes a 1.5% latency increase (Table 10.1).

Table 10.1: Table listing the expected overhead costs using TinySec for a 24 byte data payload. The packet overhead includes space needed for the header and media access control information. Since TinySec increases the packet size by a fixed amount, it will increase the time needed to send the packet over the radio. This impacts bandwidth, latency, and the energy needed to send a packet [19].

Application Data (b) Packet Overhead (b) Total Size (b) Time to Transmit (ms) Increase Over Current TinyOS Stack Current TinyOS Stack 24 39 63 26.2 — TinySec-Auth 24 40 64 26.6 1.5% TinySec-AE 24 44 68 28.8 8.0%

To measure TinySec performance costs the impact of TinySec on bandwidth, energy, and latency on the Berkeley Mica2 sensor nodes are considered. The term ―byte time‖ is the time to transmit a single byte over the radio which is directly related to the packet transmission time.

Figure 10.9 shows the result of the measurements for end to end latency in a system using TinySec. It is stated that 37 nodes are used for this test and the time it took to send a message over some number of hops is calculated. It is seen that TinySec increases the message reception latency because it increases the packet lengths and longer packets take longer time to transmit.

Figure 10.9: End to end latency measurements [19].

As the TinySec authentication only feature increases the packet lengths only 1 byte, its latency is nearly the same where no security is used. However if TinySec AE is used message latency increases.

Figure 10.10 shows the increase in latency when sending packets in TinySec Auth and TinySec AE modes. It is seen that if TinySec AE mode is used latency is increased by 4.6 byte times. As TinySec AE adds extra 5 bytes to the packets the result is consistent. If encryption is not used and the packets are sent in TinySec Auth mode theoretically 1 byte time should be observed and according to the measurements 1.1 byte time latency increase is observed.

Figure 10.10: Increase in latency when TinySec is used (byte times) [19]. For testing the consumed energy a single mote running a simple application that sends packets is used. The consumed energy for sending a packet with the default stack is calculated as 0.00016 mAH by using an oscilloscope. If packets are transmitted in TinySec Auth mode the consumed energy is calculated as 0.000165 mAH, and if TinySec-AE mode is used to transmit the sample packets the consumed energy is increased to 0.000176 mAH (Table 10.2).

Table 10.2: Total energy consumed to send a 24 byte packet. Energy (mAH) Increase Current TinyOS Stack 0.000160 —

TinySec-Auth 0.000165 3%

Figure 10.11 shows the current in amperes with respect to time. It is seen that using TinySec authentication only feature increases energy consumption by 3% and if the TinySec authentication and encryption feature is used the increase in energy consumption is 10%. It is stated that for TinySec Auth 1% of 3% energy overhead comes from increased packet length and 2% from extra cryptographic computations. For the TinySec AE mode 6% of 10% energy overhead comes from increased packet length and 4% from extra cryptographic computations.

Figure 10.11: The power consumption for sending a packet [19].

Another performance measure is done on the maximum throughput as the total number of packets that could be sent successfully in 30 seconds with variable number of senders and 24 bytes of application data. TinySec-Auth's bandwidth is very close the current TinyOS stack but TinySec-AE causes a bandwidth decrease by 6% which sends 5 byte larger packets (Figure 10.12). Throughput difference seems

Figure 10.12: Bandwidth, plotted as a function of the number of send-receive pairs. We compare TinySec with and without authentication to the bandwidth without

using TinySec [19].

It is also computed that routing with TinySec-Auth takes more time than the routing with the current TinyOS radio stack and additionally routing with TinySec-AE takes more time than both of them.

It is seen that the energy, bandwidth, and latency overhead of TinySec is less than 10% where most of the overhead is caused by the increased packet length. ―It is also

obtained that the additional energy cost for the cryptographic computations is 2/3 of the total energy increase of TinySec-AE‖ [19].