Control component

Interfaces and operation

The control component interfaces with TinyOS and every other SecRose component in order to coordinate secure communication.

When the higher layers of TinyOS wish to send a packet, they pass it to the control component. The packet‟s contents are then built and processed to facilitate packet management, encryption and authentication. This process is done by requesting the related services of other SecRose components. Finally, the packet is passed to the lower TinyOS layers for transmission.

Packets are received by the lower layers of the TinyOS and are then passed to the control component. The component then decrypts and validates the packet. Valid packets are passed to the higher layers of TinyOS.

Note that packet data is a superset, which includes the packet fields and other information. Some of the packet data are not transmitted.

Packet management

The packet management system is an important subcomponent. It facilitates the three basic packet types: normal, broadcast and long packets. It also recognises and handles

acknowledgement packets. Every packet has to be processed by packet management before any other action takes place.

Outgoing packets are given a flag value, depending on communication type. For incoming packets, the flag is examined and the actual destination address is derived from the flag. Outgoing packets are then passed back to the control component to continue the operations. Incoming packets continue to be handled by packet management until their reception is completed.

Packet management has to coordinate the actual transmission and reception because transmitted packet fields depend on packet type. Outgoing packets are given back to the packet management component when the other components have finished processing and the

106 packet is ready for transmission. Only the relevant packet fields are selected from the packet data for transmission.

The flags that are utilised by the packet management can be used for additional efficiency savings by facilitating early rejection of unwanted packets. The rejection happens in this component.

Outgoing packets

After packet management has processed the packet, the control component requests a MAC to be calculated by the authentication component. When this concludes, the packet is sent to the encryption component to encrypt it.

The packet is then passed back to packet management for transmission and when that finishes the control component informs the key management system that a packet transmission event has concluded. Finally, the control component is ready to process the next packet.

Incoming packets

When a packet arrives from lower layers, it is initially processed by the packet management subcomponent. The finalised packet is passed to the control component and the encryption component is invoked to decrypt the contents of the packet. Then the packet is passed to the authentication component to validate the authenticity and integrity of the packet. An acknowledgement packet is sent if the validation succeeds.

If validation fails, the control component asks the key management system to revert to the backup pair key and repeats the decryption and validation steps again. An acknowledgement packet is not transmitted in this case.

Acknowledgement packets

Authenticated acknowledgement packets are sent when packets are received and validated with the first attempt. The process is straightforward and invokes the control component and the packet management subcomponent only.

107 Acknowledgement packets do not contain any data and thus the encryption component is not invoked. The authentication component is not needed either, since it has already processed the received packet and has produced the required authentication data.

The control component feeds packet management with the acknowledgement packet data and the acknowledgement packet is generated on the fly by the field selection of packet management.

As it has been discussed already, there are cases where acknowledgement packets are not transmitted. This behaviour is a consequence of the original intentions of the acknowledgement packets and the subsequent system design.

The aim of acknowledgement packets is to maintain pair key state, not to confirm proper reception of a packet. Packet reception is a side effect of the acknowledgements. With the current SecRose operation specification, transmission of acknowledgement packets, when the initial MAC validation has failed, would result in loss of synchronisation.

If a receiver is required to use the backup key to validate a packet, it makes a permanent change in the counter table, promoting the backup counter to active counter. The system is not in ideal state but it is operational because the two active counters are synchronised. Transmission and reception of acknowledgement at this point would cause the sender to advance its active counter using the counter update value. It will therefore cause complete loss of synchronisation, since no counter will be synchronised after that.

SecRose intentionally operates in this way to avoid using energy-expensive acknowledgements when the key cannot be easily updated. It might be that both communication ends have calculated the counter update value and can therefore update the active key. However, the sender would have to acknowledge the initial acknowledgement in order to let the receiver know that it received that acknowledgement.

That would be an unnecessarily energy-expensive and complicated process with little benefit. Consider that the acknowledgement of the acknowledgment would also have to be acknowledged and so on. This research did not find a solution to this problem and thus SecRose is required to allow some key reuse to happen.

108 The SecRose proposal might be different from the usual but it is still consistent with the TinyOS acknowledgements. TinyOS includes a data-link layer acknowledgement mechanism, in which neighbouring nodes report that they have received the outgoing transmission. It does not give any information about what happened in the rest of the hops until the final receiver.

SecRose‟s acknowledgement operates in the transportation layer, informing the sender that the final receiver has received the acknowledgement or that some kind of error had occurred. Further work in SecRose might improve it to give acknowledgements with specific errors but they need to be carefully considered in terms of energy consumption.