Running GridTrust

It is assumed that prior to running you have finished setup for the server, native device, interfacing device, and two PUF boards (one board connected to the native device, one board connected to the interfacing device).

It is also possible to run GridTrust with only the server and a single device.

Networking Notes:

• • It is assumed that the server, native device, and interfacing device are all on a LAN network and have been assigned IPv4 addresses.
  • In our setup, the server was connected directly to the router via ethernet connection, and the router was connected to a switch via ethernet connection
  • The interfacing device and native device were both connected to the same switch via ethernet connection
  • On the Fedora environments for the server, native device, and interfacing device, the IPv4 address, netmask, and gateway for the ethernet connection must be specified manually in the network settings
    • In our setup, we used the following:
    • Server IPv4: 172.23.2.200
    • Native Device IPv4: 172.23.2.205
    • Interfacing Device IPv4: 172.23.2.210
    • Netmask (for all): 19
    • Gateway (for all): 172.23.0.1

Starting

1. Start the server

• • • Start Docker: sudo docker-compose up -d
    • Start Nginx: sudo systemctl start nginx
    • Start the server: cargo run
    • If the server starts successfully, you should see the following in the terminal:
      • Finished ‘dev’ profile [unoptimized + debuginfo] target(s) in 0.11s
      • Running ‘target/debug/server’
      • “Local” (or “Push” or “None,” depending what update type has been configured in the PSQL database)

2. Start the native device

• • • Connect the PUF board and the temperature sensor to the native device computer
      • One USB connection for each
    • Test the network connection between the native device and server from the natibe device computer: curl https://<common name you configured when setting up the server certificate>:3030, in our case, we used curl https://172.23.2.200:3030
    • Should see: HTTP method not allowed
      • If you see a bad gateway HTML printout, then the SELinux policy has not been set to permissive (see server setup)
    • Ensure you are in the Rust project root directory for the native device project (Cargo.toml will be in this directory)
      • cargo run
      • Common errors and issues:
        • Failed to open serial port: Error { kind: Io{PermissionDenied}, description: “Permission Denied” }
        • Solution: sudo chmod 666 /dev/ttyACM0 (or replace /dev/ttyACM0 with the serial port the native box is connected to), and then cargo run  again
        • The same serial port permission error above can happen for both the PUF and temperature sensor. Run the same command above for whichever ttyACM port the PUF is connected to
        • When performing cargo run for the first time, some crates (Rust dependencies) need to be downloaded, which requires an internet connection
        • However, the ethernet on the native computer is used for the LAN between the server, native device, and interface device
        • Solution: temporarily disconnect from ethernet and connect to WiFi to download the crates, then disable WiFi and reconnect to ethernet (or just connect to a non-LAN ethernet)
          • The native device code is configured to continuously log temperatures in the terminal while concurrently transferring data to the server
      • If the native device program runs successfully and authenticates the update, you should see the following behavior in the terminal on the native device computer (this specific case is for a local update):
        • Three temperature printouts, one temperature per line, three-second delay between each temperature
        • Enc counter at client: <some encrypted counter value>, depending on what the synchronized counter between the client and server is
        • Installing update from local files
        • directory /local_updates/update64.txt
        • The program will loop from here, use ctrl + c to terminate
      • If the native device program runs successfully but does not authenticate the update, the native device should receive an update type of None and not proceed with any updates
      • Similarly, if the update is performed successfully, you should see the following behavior in the terminal on the server computer (this specific case is for a local update):
        • Database stored values:
        • Key: (key in the database), Counter: (counter in the database)
        • Counter (counter in the database)
        • Key (key in the database) 
        • enc_ctr from Server: (database counter encrypted with AES128-ECB)
        • enc_ctr from Device: (PUF-stored counter encrypted with AES128-ECB)
        • Ctrs Match
        • …
        • Updating device

3. (Optional) Start the interfacing device

• • • Same steps as starting the native device

Changing Update Type

The PostgreSQL database on the server controls which update type is to be performed.

Access the database and run one of the three commands below to change between a local update (update files are on the native or interface device), remote update (server pushes the update files over ethernet), or none (no update scheduled/allowed).

A change of update type requires the Rust program for the server to be restarted to take effect.

• • UPDATE updatetype SET updatetype=’Local’;
  • UPDATE updatetype SET updatetype=’Push’;
  • UPDATE updatetype SET updatetype=’None’;

Changing Update Files (Locally)

If the update type is set to “Local” then the update files (update64.txt, util_sign64.txt, vendor_sign64.txt) must be placed on the target device (native or interface device computer) in the following location:

./local_updates/ relative to Cargo.toml

Changing Update Files (Remote Update)

If the server is providing the update files, the update files for a device must be placed in the following corresponding location on the server:

./update_files/tempsensor/ relative to Cargo.toml

./update_files/relay/ relative to Cargo.toml