| Introduction |
Recently, there has been a lot of interest in the creation of low cost ad-hoc sensor networks. Few deployments of such system have been made to date. As these deployments occur in the real world, there will be a need to protect the sensor network from various types of attacks. This is particularly challenging in an environment where the network is designed to be flexible: with automatically configured routing and with the ability to modify the functionality of the network as a whole. How do we protect the such a system from subversion while maintaining this flexibility? In this project, we plan to investigate the security issues arising in the deployment of sensor networks.
Before we define what we are going to protect, we shall define the capabilities of the adversary. The attacker can take over any node
within a network (but subverting all nodes is not possible). Subverting a single node means that that all nodes within
communication radius of that node can be denied receiving any information (they still may be able to send information). We seek to minimize the impact of a subverted
node on the rest of the network: in particular, the single node should not grant the attacker the ability to subvert the entire network. Note
that in a network with a single gateway (base station) the attacker needs to take over just that one node in order to render the network
useless. It is crucial that some redundancy be provided.
Sensor network nodes are typically quite limited in capability: the platform we use contains a 4 MHz processor, 8Kbytes of instruction memory, and 512 bytes of RAM. Only a fraction of processing and memory space can be devoted to cryptographic algorithms, thus it seems that the use of public key encryption is too expensive. Symmetry key cryptography is orders of magnitude cheaper, and may suffice for the sensor network applications; it still remains a challenge to use nontrivial cryptography with such limited resources in an environment where crypto is not the sole application of the device.
In order to understand what aspects of security might be important for sensor networks, we need to first look at the types of data flowing through the network. Currently we identified 3 types of messages: sensor readings (either raw or aggregated), network management messages (routing updates, etc.), and node management messages from the base station (reprogramming, timing info, reset requests). The sensor networks we built so far had limited peer-to-peer communication. We examine the expected properties of each type of messages.
In general, we can only place limited trust in the values of sensor readings. Since we cannot guarantee physical security of a node, the node could be tricked into producing arbitrary sensor readings. It is through the process of data analysis and distillation from multiple nodes in that local area that we can arrive at a more reliable reading. In order to process the sensor data, it is often useful to be able to identify the node which produced a particular set of readings. Our prototype hardware has no physical security of the node address (like Ethernet addresses), but cryptographic techniques could be used to prove the identity. A base station could share a private key with a sensor node; the readings could be either merely authenticated using that private key or encrypted. If the node needs to authenticate a reading to several nodes, a TESLA-like protocol could be used.
Network management messages are quite fundamental in ensuring that the attacker cannot use a single node to subvert the entire network. Authentication of messages seems to be the key application; we plan to investigate how to use authentication in the context of the routing protocols.
The problem of node management seems to involve two types of communication: either base station to individual node or a broadcast from a base station. In the case of a broadcast, authentication of messages is most important, while securing the channel seems significantly less important (since an attacker can take over a single node). In this case, the authentication can be provided via TESLA. The base station to individual node communication can be either encrypted or merely authenticated. The encrypted communication between the node and the base station could be useful for key management.
As we mentioned above, in this regime meeting the processing and memory requirements while providing nontrivial guarantees can be quite a challenge. In that regime we would like to see few cryptographic algorithms used in conjunction with protocols to provide a number of security properties in the system. Our initial research indicates that Rijndael seems to be well suited to our applications. At this point we anticipate the following challenges:
| Protocols |
M->B nonce|request
B->M E(nonce|request, K1) | MAC(K2, MSG)
Interesting observations:
specifying the nonce gurantees freshess, but it may not be necessary. In
particular, our encryption scheme uses sequence numbers as IV in the OFB
encryption; it is easy to check that the message has been encoded with
the appropriate sequence number (which serves as the nonce).
Since IV is known, the pad can be precomputed, which makes decryption
almost free. The pad can be precomputed after the request has been sent
but before reply has been received; classic communication/computaion
overlap.
Use Kerberos-like scheme.
It seems that it would be nice for any mote to authenticate the data coming from neightboring sensors. The purpose of the aggregation is to reduce the amount of data propagating through the routing tree; we need to be able to dynamically create groups, etc. We settled on a not particularly elegant, but simple scheme: the routing node sends a request to the base station which includes the IDs of all the nodes that want to form a group. Each node shares a secret with a base station. The base station then chooses a random key, and sends the encrypted version of that key to each participant in the group. In order to save BW, we might compress these messages into a single message containing the n copies of the group key encrypted each encrypted with a participant key. Again, we use the protocol 1 to provide the right communication abstraction; the nice property of such scheme is that it involves a round trip to the base station and a local broadcast, but no global broadcasts.
We still need to think about the issues of group authentication, dynamic membership, etc. while trying to create a very efficient system (remember performance and memory limitations) as well as trying to exploit some properties of the communication medium: localized broadcast is the primitive; localization is the key to data aggregation.
Additionally, Rob insists that we do not need an overkill security, only as good as we can get without assuming physical security of individual nodes. I tend to agree.
| Resources |