Lab 4: Physical layer — Radio Signal Strength [7 points]

Important: Research how to stop a Linux service called Network Manager. This service can cause interference with your code if you leave it running.

1. [2 points] Implement a search and rescue locator.

   In a disaster such as a building fire, or an earthquake, it can be difficult to quickly locate survivors. Time is often critical in these situations. In this exercise you'll implement a system where a survivor's device rapidly transmits a custom Wi-Fi "beacon" frame. Rescuers run another program on their device that detects the presence of those beacons and measures the signal strength. Rescuers can determine if they are getting closer (e.g., increasing RSSI) or farther (e.g., decreasing RSSI) from a survivor's beacons as they search. The rescuer's program should help them find survivors more quickly than if this system did not exist by giving the rescuers guidance on which way to move. For convenience, we will implement both the survivor's beacon program and the rescuer's program on a laptop using the VM. In the real world, such a system could be implemented on a smart phone or smart watch, which is likely to be located with the survivor when the disaster strikes.

   Complete the following:

   1. [0.25 point] Monitor mode. To measure RSSI, a Wi-Fi adapter must first be put in monitor mode. Research what monitor mode is, and how to set it on Linux. Write a simple bash script to set monitor mode on the Wi-Fi dongle. Your script should take the Wi-Fi adapter's name (e.g., wlan0) and a channel as parameters. Your script should set the Wi-Fi adapter to monitor mode on the channel given by the parameter, then should run a command so the user can confirm the interface is indeed in monitor mode. Write your own bash script, do not just install and call airmon-ng. In a short write-up, describe why setting the channel is important and provide terminal output from your script showing it successfully set monitor mode. Call this script from both your survivor and your rescuer code to set the Wi-Fi adapter into monitor mode (e.g., save a copy of this script on both the rescuer's and the survivor's computer).
   2. [0.25 point] Beacon design. Design a "beacon" frame to be transmitted by the survivor's device. The frame should be easily identifiable by the rescuer's program among all the other packets that might also be in the air. You may use any network layer you choose for this beacon, there are many possible choices. Consider the fact that there may be multiple survivors in an area. You should be able to tell survivors transmissions apart. In your write-up, describe what information your beacon contains that would help rescuers and when/how often you will transmit these beacons. Also in your write-up, discuss the idea of using RSSI as a proxy for distance and give examples of where it could go wrong. Is RSSI a good proxy for distance in this rescue use case?
   3. [0.5 point] Implement the survivor program. Implement the survivor program that will transmit your "beacon" frames for rescuers to detect. Hint: you will need to include a RadioTap header on the survivor's packets.
   4. [1 point] Implement the rescuer's program. Implement the rescuer's program to measure and display RSSI from each survivor within radio reception range. Rescuers will run this program while searching for survivors. As rescuers walk around searching for survivors, your program should allow them to see if they are getting closer or farther from the survivor based on RSSI. Rescuers will move toward increasing RSSI to find the survivor. If they see RSSI dropping, they will reverse course. Your GUI need not be elaborate, but should use ncurses (recall from CS50) to update in real time and should be able to show the presence of multiple survivors with their signal strength and the time their beacon was last seen. You may need a multi-threaded solution to sniff on one thread and update the GUI on another thread.
   5. [Required] Video. Make a short video showing your system in action. One partner, the survivor, should run the beacon program and hide, while the other partner attempts to locate them using the rescuer's program. Make sure both the survivor and rescuer are on the same channel. Without the video, the survivor and rescuer implementation points are not awarded. Be careful while walking around with your laptop open and filming (do not traverse stairs)!

2. [5 points] Secret key for device introduction.

   When a person buys a new Internet of Things device, they commonly want to introduce the new device to other devices they own so the new device can securely communicate with their existing devices. In this exercise, you'll use Wi-Fi RSSI to create the same key on two devices that are in physical proximity to each other. That key can be the basis for establishing long-term secure communications between the devices. This idea is called key exchange and was the subject of a Dartmouth undergraduate's senior thesis that resulted in a U.S. patent.

   For this exercise, place two devices in close physical proximity (about 1/2 meter apart or so, the exact distance is not critical — the devices just need to be fairly close) then wave your hand between the devices while the devices rapidly send frames between themselves. The motion of your hand will cause periods of constructive and destructive interference in the signal as discussed in the class. Each device should measure the RSSI of the frames it receives, then should quickly reply with a frame to the other device. The other device then measures the RSSI and replies back with new frame. In this way the devices quickly trade frames back and forth while the hand movement causes a difficult-to-predict pattern of strong and weak RSSI measurements.

   A principle called reciprocity says that the constructive/destructive interference caused by your hand waving will be the same in both directions (e.g., same interference from device 1 to device 2, as from device 2 to device 1), provided frames are exchanged quickly (e.g., device 1 measures RSSI and responds quickly to device 2, device 2 measures RSSI and should get a similar measurement as device 1, if the hand didn't move too far, but probably will not measure exactly the same RSSI).

   You will run the same code on two devices. One device will be the initiator and the other the responder. While trading frames, the initiator will assign the frame an index from 0 to n if n frames are exchanged, and will send it to the responder (you will need to find a way to encode the index on the frames the initiator sends). The responder will receive each frame and will store the frame index and RSSI. The responder will then quickly reply to the initiator with a frame that encodes the initiator's index. Like the responder, the initiator will measure the reply frame's RSSI and will save the index and RSSI. In the end, each device will have a list of indices and RSSIs. These RSSI values will likely differ on each device for a given index, but should have a similar pattern of strong and weak RSSI measurements caused by constructive or destructive interference imparted by your hand's movement while exchanging these n frames. We will use these RSSI values to form a key as described below. Some frames may be dropped, you will need to deal with that occurrence.

   Complete the following:

   1. [1 point] Determine roles. Each device will start running your program (e.g., both devices run the same program) and should first check to see if another device is transmitting your own custom "ready to begin" frames. If so, this device is the responder and should tell the initiator it is ready to exchange packets by sending a custom frame of your choosing. If there is no transmitting device, this device is the initiator and should start transmitting your "ready to begin" frames and wait for a response from a responder. Timeout after a short period if no responder is heard. Write the code to allow two devices, each running the same program, to determine if they are the initiator or responder (e.g., you will not start one program and tell it that it is the initiator and start the program on another computer and tell it that it is the responder — devices determine roles automatically).
   2. [1 point] Frame exchange. After establishing roles, write code for each device to quickly exchange frames, noting the index and measuring the RSSI for each frame as described above. Each device will end up with its own list of the indices and RSSI values it measured from each frame. You can send a fixed number (say n = 300) frames between devices.
   3. [1 point] Calculate a key on each device. Create a key composed of 0 and 1 bits derived from its list of RSSI values. These RSSI values will be similar on both devices, but probably not exactly the same for any given index. Because the RSSI values will not be exactly the same, you cannot simply concatenate RSSI values to form the same symmetric key on both devices. Consider this approach instead, where each device independently:

      Starts with a key of length zero
      Calculates the average and standard deviation of its stored RSSI values
      For each stored RSSI value at index 0 ... n     
        Append a 1 bit to the key if the RSSI value at that index is z standard deviations above the mean
        Append a 0 bit to the key if the RSSI value at that index is z standard deviations below the mean
      Each device now has a key made up of 1 and 0 bits

      Some indices will not be used to generate a key bit (e.g., the RSSI was not more than +/- z standard deviations from the mean). Discuss reasonable values for z in your write-up.

   4. [1 point] Keep common bits. Each device will likely drop some frames (for example by failing CRC checks) and sometimes one device will compute a 1 or 0 value for an index based on the mean and standard deviation, but the other device may not calculate enough of a difference from the mean to use that index as a 1 or 0 bit. Devise a method for devices to determine which indices they used in common to compute the key. Keep bits in the key where the bit's index was used by both devices (e.g., where the RSSI was more than +/- z standard deviations from the mean on both devices), discard the other bits. Note: you can exchange which indices were used, but you should not exchange bit values.
   5. [1 point] Confirm resulting key. Confirm each device has calculated the same key. Design a method for one device to commit to a key without revealing the exact sequence of 1 and 0 bits and for another device to determine if its key matches. Consider the method successful if the second device can confirm its key matches the first device's key, even though it did not receive the other device's 1 and 0 bits. You can stop here, you do not have to implement bootstrapping a long-term secure key. Also, if you send, say 300 frames in the exchange, devices may have used a small number of bits in common. In your write up describe how bits should be included in a cryptographic key that will serve as a basis for long-term secure communication. For this lab, you do not need to ensure you got that many bits in your key, but your key should have at least one bit! Show evidence both devices independently computed the same key.

Submission Instructions

Create a single .pdf file with your write-up containing answers to the questions above. Zip your code files and video together with your .pdf into a single file and submit that file via Canvas. In the text box on your Canvas submission, provide the name of your partner. Both partners should submit the same file.

Be sure to include the header comments specified in Lab 1. Make sure to credit any AI assistance.

Grading rubric

Total points: 7

• [2 points] Search and rescue
  • [0.25 point] Monitor-mode script and write up. Terminal output showing monitor mode set
  • [0.25 point] Beacon design and write up (frame contents, transmit cadence, RSSI-as-distance discussion)
  • [0.5 point] Implement survivor program
  • [1 point] Implement rescuer program (real-time ncurses display, multiple survivors, last-seen time)
  • [Required] A short video demonstrating the survivor hiding and the rescuer locating them. Without the video, the survivor and rescuer implementation points are not awarded.
• [5 points] Secret key exchange
  • [1 point] Determine roles
  • [1 point] Frame exchange
  • [1 point] Calculate key on each device
  • [1 point] Keep common bits
  • [1 point] Confirm resulting key