*************************************************************** * README for "TinySeRSync: Secure and Resilient Time * synchronization in wireless sensor Network". * * Author/Contact: Kun Sun, ksun3@ncsu.edu * Panos Kampanakis, pan_kamp@ncsu.edu *************************************************************** 1. INTRODUCTION -------------------- TinySeRSync is a software package providing both secure single-hop pair-wise time synchronization and secure and resilient global time synchronization on MICAz motes running TinyOS. The secure single-hop pair-wise time synchronization protocol uses hardware-assisted, authenticated medium access control (MAC) layer timestamping. Unlike the previous attempts, this technique can handle high data rate in MICAz motes (in contrast to the low data rate in MICA2 motes). The secure and resilient global time synchronization technique is based on a novel use of the \muTESLA [2] broadcast authentication protocol for local authenticated broadcast. We solved the conflict between the goal of achieving time synchronization with \muTESLA-based broadcast authentication and the fact that \muTESLA requires loose time synchronization. The resulting protocol is secure against external attacks and resilient against compromised nodes. For details see the related publication [1]. 2. INTERFACES PROVIDED ---------------------- Interfaces (1) to (6) are implemented by Kun Sun. (1) SecSync.nc is the interface for setting the synchronization intervals in secure and resilient time synchronization. (2) SecTimeStamp.nc defines the interface for generating a timestamp when the SFD field in an IEEE 802.15.4 frame is sent out or received. (3) PairwiseKey.nc defines the interface for pair-wise key storage and access. (4) buffer.nc defines the interface for buffering the unauthenticated global synchronization messages. (5) KeyChain.nc define the interface for key chain generation (using SHA-1) and that for key verification. (6) Timer3Handler.nc includes two events to handle the comparison output of register B and C in timer 3. Interfaces (7) and (8) are based on other people's excellent work. (7) Sclock.nc provides a logical clock by using Timer3. It is based on the TPSN implementation by UCLA. (8) SHA1.nc provides the implementation of SHA-1 hash function by An Liu at NC State University. 3. OTHER CHANGES IN TINYOS -------------------------- TinySeRSync requires modification of the radio stack in TinyOS. The following describes these modifications. (1) tinyos-1.x/tos/lib/CC2420Radio a) Before sending pair-wise or global synchronization messages, it reads and adds current logical clock time in the messages. b) When receiving a pair-wise synchronization message, it verifies the Message Integrity Code (MIC) in the message; when receiving a global synchronization message, it changes the length field to include the MIC field. c) When handling the SFD capture events, it signals upper layer about the send or receive time. (2) tinyos-1.x/tos/platform/micaz a) Implement command "HPLCC2420RAM.read()" in file "HPLCC2420M.nc". b) Change event "captured(uint16_t time)" to "captured(GTime time)" in the interface "TimerCapture.nc". 4. OPERATION / EXPERIMENT OVERVIEW ---------------------------------- TinySeRSync uses three kinds of nodes. The source node of time synchronization, the nodes that are synchronized, and the sink node that is responsible of sending anchor messages and queries to collect the time responses to be used to verify if synchronization is achieved. (Note that the sink node is only needed to perform the data collection task in the default test experiment; it is not necessary for TinySeRSync. The sink node should be connected to a PC through the serial port.) Each node discovers its neighbors and begins secure single-hop pair-wise time synchronization with each of them after it is powered up. The source node initiates the secure global time synchronization after it is powered up. In the current implementation, the ID of the source node is set to 1 and the sink is set to 100 by default. These can be easily changed by slight modification in the source code. For the convenience of experimentation, the motes blink their LEDs to signal the progress of time synchronization. When initiating a single-hop pair-wise synchronization, each node blinks its green LED. The source node does not need to initiate this process (i.e., its neighbor nodes initiate pair-wise synchronization with the source), and thus its green light is never on. The red and the yellow LEDs blink whenever two nodes are synchronized. In our default test experiment, where the sink node is included, the other nodes do not perform any synchronization until the sink node sends a start message. This is done to have more precise measurements on the synchronization time. The sink node blinks its red LED when it sends its queries, and blinks its green LED when it collects data and sends it back to the PC through the serial port. To capture data collected from the sink node, we include a free program called Terminal.exe. It captures data coming in from the serial port. Any other software capturing from the serial port connected to the sink could be used in the experiment. 5. HOW TO INSTALL ----------------- We have included all the source code to repeat the experiment described in Section 7.4 in [1]. Other experiments can certainly be done easily with slight modification of the code. In this section, we describe how to install the code to the motes. In the next section, we explain how to repeat the aforementioned experiment. Assume we have one source node, one sink node, and 60 MICAz motes to be synchronized. 1) Install TinyOS 1.1.14 or later. It is available at http://www.tinyos.net/download.html. 2) Extract TinySeRSync.zip to a local directory. 3) Copy/overwrite the files to corresponding directories in TinyOS. 4) Compile and install program. For MICAz motes, assume mib510 Programming and Serial Interface Board, which is connected to, for example, COM4: - set up the source node from the apps\TestSecSync directory $make micaz install.1 mib510,/dev/ttyS3 - set up the other 59 nodes from the apps\TestSecSync directory $make micaz install.2 mib510,/dev/ttyS3 $make micaz reinstall.3 mib510,/dev/ttyS3 $make micaz reinstall.4 mib510,/dev/ttyS3 ... $make micaz reinstall.60 mib510,/dev/ttyS3 - set up the sink from the apps\MySink directory $make micaz install.100 mib510,/dev/ttyS3 6. HOW TO RUN THE EXPERIMENT ---------------------------- After we have installed the code on all the MICAz motes (60 in total), we are ready to run the experiment described in section 7.4 of [1]. (1) First we form a grid as described in [1] with all the nodes and power the first 49 on. (2) Connect the sink node to a mib510 and to a computer. We don't power it up yet. (3) Run the Terminal.exe and set it up to capture the data from the port connected to the mib510 with the sink on it. The baud rate should be 57600. Press connect, so now Terminal.exe is ready to capture data from the sink. Note that you can set it up to log the data in a log file. (4) Power on the sink node. You will notice that when you power it on, all the other nodes except the source will start blinking their green LEDs. Gradually as they are synchronized their red and yellow LEDs will start blinking too. (5) At the same time, the sink node blinks its red LED whenever it is sending anchor messages, and blinks its green LDS whenever it receives and forward a reply to the serial port. (6) 10 minutes later, turn off the sink, power up the next 5 nodes and power up the sink again. If you are capturing the data in a file, then make sure that you capture it to another one from now on because they will be mixed up later. (7) 1 minute later, power down the sink, power up the last 6 nodes and turn on the sink again. Don't forget to save the data in a new file to avoid confusion again. (8) A couple of minutes later turn off all the nodes, disconnect the serial, disconnect Terminal.exe from the serial and keep all the capture log files from the nodes. So now, you must have three files with 6 columns in each one. The ones you will use for the data analysis will be the first(node id), the second (round), fourth (mticks) and fifth (sticks). When two nodes are synchronized then ideally the mticks and sticks for the same round should be equal. The time in each node is given as (mticks + sticks) where 1 mtick = 568.8 ms and 1 stick = 8.68 us. Use any way to analyze data, and verify that the nodes are well synchronized. You can obtain Fig 10 of [1]. 7. NOTES -------- 1) By commenting out the line CFLAGS+=-DDATA_COLLECT from the apps\TestSecSync\TestSecSyncM.nc, the nodes will only perform synchronization. This can be inferred from their corresponding lights blinking. The sink node doesn't have to be present. Data will not be collected. 2) You have to restart the sink node when turning on late nodes in the experiment for them to start the synchronization procedure. In other words when using a sink node to collect data it has to be powered after the nodes. This is a limitation of the data collection program. 3) Tolerance is defined in the tos\system\SecSync.h and by default is set to 0 for the experiment. The value of tolerance indicates the maximum number of colluding neighbors of each normal node that can be tolerated by TinySeRSync. 4) The neighbor nodes identify themselves manually but this can be also achieved by using Hello messages (commented out in the code). 5) Bear in mind that whenever the sink node is powered on it starts sending anchor messages starting from round 0. So, if the files that you have captured all start from round 0 whereas they should be consequeti,ve that is because you had to restart the sink node whenever you want to add some nodes in the experiments. But the files can still be used to analyzed the data, by just adding the reference value to all the round values. Note that this is a limitation of the data collection program, not a problem with TinySeRSync. 6) The key length is 16 bytes. Struct Pairwise_Key_t defined in file tos\system\PairwiseKey.h is used to store the pair-wise key shared with each neighbor. For simplicity, we set the pair-wise key manually in our experiments. However, it can be replaced by any key management mechanisms for sensor networks. 7) The following table shows the parameters in the package Parameters | Definition | Default Value | Definition File ----------------|---------------------------------------|---------------|------------------ SYNC INTERVAL | global synchronization interval | 10 s | apps\TestSecSync\TestSecSyncM.nc PW INTERVAL | pair-wise synchronization interval | 500 ms | apps\TestSecSync\TestSecSyncM.nc LONG INTERVAL | pair-wise synchronization interval | 500 ms | apps\TestSecSync\TestSecSyncM.nc SHORT INTERVAL | uTESLA short interval | 128 ms | tos\system\KeyChain.h SRC NODE | the ID of source node | 1 ms | tos\system\SecSync.h TOLERANCE | No. of compromised nodes in neighbors | 0 ms | tos\system\SecSync.h 8. REFERENCES ------------- [1] Kun Sun, Peng Ning, Cliff Wang, An Liu, Yuzheng Zhou, "TinySeRSync: Secure and Resilient Time Synchronization in Wireless Sensor Networks'', in Proceedings of the 13th ACM Conference on Computer and Communications Security (CCS'06), Alexandria, VA, November 2006. [2] A. Perrig, R. Szewczyk, V. Wen, D.Culler, and D. Tygar, "SPINS: Security Protocols for Sensor Networks". In proceedings of Seven Annual International Conference on Mobile Computing and Networks, pages 521-534, July 2001