Skip to content

HamoodQ/trust_project01

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

IoT Trust

Internet of Things (IoT) applications are intended to be used to solve issues in a range of settings, ranging from building security to smart city surveillance and emergency response. Many IoT devices, on the other hand, are resource limited and lack the capability or knowledge needed to compute results for tasks that they may be asked to perform. Instead, these tasks would need to be offloaded to a server at the network's edge in order to respond quickly. Since these networks will have multiple organisations providing multiple IoT nodes and Edge nodes with varying capabilities, IoT devices will need to know which Edge server they can rely on to respond to a task in a timely manner.

This repository contains a working example of such a framework for trust-based task offloading. We include two examples of applications as well as a variety of trust models.

Repository Structure

The following is the layout of this repository, with the most relevant implementation in:

  • The implementation of firmware for IoT and Edge nodes is contained in /wsn/node and /wsn/edge respectively.
  • The implementation of two example resource-rich applications and the root node application is contained in /resource_rich.

Other directories contain supporting code:

  • The /tools and /tests/run directories contains various tools in order to setup and run experiments
  • The /analysis directory contains scripts to analyse and graph results from experiments

Setup

This system assumes the use of Zolertia RE-Mote rev.b hardware for IoT deployments. Parts of the implementation depend on the hardware accelerated cryptograpic operations they provide.

Development

  1. Install dependencies
sudo apt-get install git build-essential gcc-arm-none-eabi python3 texlive-extra-utils cm-super texlive-latex-extra dvipng poppler-utils
python3 -m pip install pexpect
  1. Download Contiki-NG
mkdir ~/wsn
cd ~/wsn
git clone -b https://github.com/HamoodQ/contiki
git submodule update --init

Edit ~/.bashrc to add the path to Contiki before the interactivity check:

export CONTIKING_DIR="~/wsn/contiki"
export COOJA_DIR="$CONTIKING_DIR/tools/cooja"
  1. Clone this repository
cd ~/wsn
git clone https://github.com/HamoodQ/trust_project01
cd trust_project01 && git submodule update --init
  1. Install Wireshark

To analyse OSCORE packets, instal the most recent version of wireshark. Instructions were created by here

cd ~
mkdir wireshark
git clone https://gitlab.com/wireshark/wireshark.git -b release-3.4
cd wireshark
sudo tools/debian-setup.sh --install-optional --install-deb-deps --install-test-deps
dpkg-buildpackage -b -uc -us -jauto
cd ..
rm wireshark-{doc,dev,dbg}_*.deb
sudo dpkg -i *.deb

Install pyshark version 0.4.3 or greater

python3 -m pip install --upgrade pyshark

If you cannot install from pip, then install from source:

python3 -m pip install --upgrade git+https://github.com/KimiNewt/pyshark.git#subdirectory=src

Using Wireshark

You must include information on the OSCORE security contexts to Wireshark in order for it to decrypt OSCORE projected packets. As of this writing, OSCORE is only supported on unreleased versions of Wireshark, necessitating the installation of Wireshark from source.

To setup OSCORE contexts in Wireshark please do the following:

  1. Select Edit
  2. Select Preferences
  3. Expand Protocols and select OSCORE
  4. Click on Edit in order to enter security contexts

The OSCORE contexts will be generated by analysis/parser/pyshark_pcap.py in a file called oscore.contexts.uat.

Root Node

  1. Install dependencies

Please note that MQTT v5 support is available, so mosquitto must be version 1.6 or later. You will need to update an older version if Debian has one and to istall from mosquitto's repository

wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
sudo wget http://repo.mosquitto.org/debian/mosquitto-buster.list -P /etc/apt/sources.list.d/
sudo apt-get update
sudo apt-get install mosquitto mosquitto-clients

Other dependencies can be installed via:

sudo apt-get install libcoap2-bin
sudo apt-get install build-essential git
python3 -m pip install cryptography more_itertools
python3 -m pip install --upgrade "git+https://github.com/chrysn/aiocoap#egg=aiocoap[all]"
python3 -m pip install --upgrade "git+https://github.com/eclipse/paho.mqtt.python.git"
python3 -m pip install --upgrade "git+https://github.com/sbtinstruments/asyncio-mqtt.git"
  1. Clone Contiki-NG
cd ~
git clone -b https://github.com/HamoodQ/contiki
cd contiki && git submodule update --init

Build the tunslip6 executable

cd ~/contiki/tools/serial-io
make
  1. Clone this repository
cd ~
git clone https://github.com/HamoodQ/trust_project01
cd trust_project01 && git submodule update --init

Resource Rich Nodes (Edges) and Resource Constrained Nodes (Monitors)

sudo apt-get install git python3-pip python3-dev pipenv python3-serial
python3 -m pip install pyserial
cd  ~
git clone https://gitlab.com/cs407-idiots/pi-client.git
cd pi-client
pipenv install

Resource Rich Nodes (Edges)

  1. Install dependencies
python3 -m pip install cbor2 pyroutelib3 more_itertools
python3 -m pip install --upgrade "git+https://github.com/chrysn/aiocoap#egg=aiocoap[all]"
  1. Clone this repository
cd ~
git clone https://github.com/HamoodQ/trust_project01
cd trust_project01 && git submodule update --init

Building the border router

The root node needs the Contiki-NG border router to be built and deployed in order to function.

On your development machine:

cd $CONTIKING_DIR/examples/rpl-border-router
make TARGET=zoul PLATFORM=remote-revb

This should have produced border-router.zoul which now needs to be copied to the root node. Replace wsn1 with the IP address or hostname of the root node.

scp build/zoul/remote-revb/border-router.bin pi@wsn1:~/pi-client/

Instructions to Deploy

A variety of test scripts have been written to assist in the running of experiments for the sake of convenience. Unless additional flexibility is needed, these test scripts should be used instead of manually running tests.

These bash scripts should be edited to customise the parameters passed to the runner scripts they call. For example, instead of the default correct behaviour, you may want to set the routing application to behave badly on the Edge node.

#nohup python3 -m tools.run.edge --application monitoring 2 --application routing 0 --application challenge_response 1 &
nohup python3 -m tools.run.edge --application monitoring 2 --application bad_routing 0 " --duration inf --approach random" --application challenge_response 1 &
  1. Specify the configuration

You will need to create a file that details the configuration of your tests. A default file exists at common/configuration.py.example that can be copied to common/configuration.py and edited. In this example file there are six devices deployed with wsn1 acting as the root, wsn2 and wsn6 acting as edge nodes, and the remaining devices acting as IoT nodes.

The hostname_to_ips variable specifies a mapping from hostnames (which needs to be configured on the linux machines acting as observers) and the IPv6 addresses of the attached IoT devices. The root IPv6 address is set to fd00::1 and is hardcoded in tools/run/root.py. The other IPv6 addresses can be found in a number of ways. One approach is to follow the Contiki-NG tutorial to ping devices. Alternatively when flashing firmware the 'Primary IEEE Address' of a device will be shown similarly to the example below. This can be converted into IPv6 address by: (1) removing the colons, (2) replacing the leading 00 with 2, (3) adding fd00:: before the 2, and finally (4) adding colons every four hex characters from the right. So 00:12:4B:00:14:D5:2B:D6 becomes fd00::212:4B00:14D5:2BD6.

Opening port /dev/ttyUSB0, baud 460800
Reading data from edge.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4
Primary IEEE Address: 00:12:4B:00:14:D5:2B:D6
Erasing 524288 bytes starting at address 0x00200000
    Erase done
Writing 516096 bytes starting at address 0x00202000

The root_node variable specifies which observer will run the root node, device_stereotypes specify the stereotype tags that should be included in the certificates of the different entities, and hostname_to_names defines alternate names that will be included in generated graphs.

  1. Build

Edit ~/wsn/trust_project01/tools/setup.py to specify the nodes used in the network then run it.

cd ~/wsn/trust_project01
./tools/setup.py <trust-model> <trust-choose>
  1. On Root
cd ~/trust_project01
./tests/run/root.sh
  1. On Observer for Sensor Nodes
cd ~/trust_project01
./tests/run/wsn.sh
  1. On Edges
cd ~/trust_project01
./tests/run/edge.sh

Instructions to Deploy (Manual)

Alternatively you can deploy applications manually instead of using the test scripts. This allows greater control over specific aspects of the deployment.

  1. Configure and build

Edit ~/wsn/trust_project01/tools/setup.py to specify the nodes used in the network then run it.

cd ~/wsn/trust_project01
./tools/setup.py <trust-model> <trust-choose>
  1. On Root

Set up tun0 interface.

cd ~/contiki-ng/tools/serial-io
sudo ./tunslip6 -s /dev/ttyUSB0 fd00::1/64

Once tunslip is running, mosquitto needs to be restarted:

sudo service mosquitto restart

The keyserver and mqtt-coap-bridge now needs to be started:

cd ~/trust_project01/resource_rich/root
./root_server.py -k keystore

You might want to consider running in developer mode with warnings on:

python3 -X dev -W default root_server.py -k keystore
  1. On Observer for Sensor Nodes
cd pi-client && pipenv shell

Find the device

./tools/motelist-zolertia
-------------- ---------------- ---------------------------------------------
Reference      Device           Description
-------------- ---------------- ---------------------------------------------
ZOL-RM02-B1002325 /dev/ttyUSB0     Silicon Labs Zolertia RE-Mote platform

Flash and run the terminal

./flash.py "/dev/ttyUSB0" node.bin zolertia contiki &&  ./tools/pyterm -b 115200 -p /dev/ttyUSB0
  1. On Observer for Edge Nodes
cd pi-client && pipenv shell

Find the device

./tools/motelist-zolertia
-------------- ---------------- ---------------------------------------------
Reference      Device           Description
-------------- ---------------- ---------------------------------------------
ZOL-RM02-B1002325 /dev/ttyUSB0     Silicon Labs Zolertia RE-Mote platform

Flash and run the terminal

./flash.py "/dev/ttyUSB0" edge.bin zolertia contiki

Now start up the Edge bridge:

~/trust_project01/resource_rich/applications
./edge_bridge.py

Plus any applications that are desired:

./monitoring.py
./routing.py

Instructions to analyse results

Obtaining Results

In order to fetch results from the devices run:

./tools/fetch_results.py results/<log-dir>

Generate pcap

If the binaries were compiled with --with-pcap then there will be a *.packet.log file for each device. This now needs to be converted to a pcap file.

pcaps can either be converted individually using ./tools/regenerate_pcap.py or processed for all packet logs in a directory using ./tools/regenerate_pcaps.py. When a large number of packets have been collected, it will be necessary to disable the timeout with --timeout None.

Individually:

./tools/regenerate_pcap.py results/2021-02-03-am-dadspp-one-good-one-bad/edge.wsn6.packet.log --timeout None

Batch:

./tools/regenerate_pcaps.py results/2021-02-03-am-dadspp-one-good-one-bad/ --timeout None

Once pcaps have been generated Wireshark can be used to view them via:

wireshark -o:oscore.contexts=results/2021-02-03-am-dadspp-one-good-one-bad/keystore/oscore.contexts.uat results/2021-02-03-am-dadspp-one-good-one-bad/edge.wsn6.packet.log.pcap

Graphing Results

There are a variety of tools to graph the results

Graphing Messages Sent and Received

To graph the number of bytes sent and received, use the following:

./analysis/graph/messages.py --log-dir results/2021-02-03-pm-dadspp-one-good-one-bad/

This tool will categorise the messages.

Trust Choose Over Time

To graph trust ranking and to whom tasks were sent over time, use the following:

./analysis/graph/trust_choose_evolution.py --log-dir results/2021-02-03-pm-dadspp-one-good-one-bad/

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages