Architecture Overview

At a high level the system consists of three entities:

  • LmP Devices
    • Execute lmp-device-register to associate the device with the gateway
    • Run aktualizr-lite and fioconfig daemons.
  • The device gateway
  • The Rest API - tooling like fioctl and app.foundries.io use
OTA architecture diagram

Devices talk to the device gateway using mutual TLS. The device gateway provides a set of REST APIs to support aktualizr-lite, fioconfig, device testing, and Docker authentication. Aktualizr-lite and fioconfig run as separate daemons that are periodically polling the device gateway with HTTP GET requests on configurable intervals.

Due to the fact devices are polling the server, REST API changes requested by tooling like fioctl happen asynchronously.

How A Device Uses Security Hardware

An LmP device uses Hardware Security Modules, Trusted Platform Module (TPM) devices or Trusted Execution Environments via the Public-Key Cryptography Standards #11 (PKCS#11) API.

They provide the guarantee that secrets will not be leaked and that communications will be secure. Certain keys will be provisioned during device manufacturing.

LmP Device architecture diagram

How A Device Finds Updates

Aktualizr-lite uses TUF to find and validate available Targets that a device may install. Aktualizr-lite will periodically check-in using this high level logic:

  • Ask if a new root.json exists. This allows a device to know about key rotations before going further. This call is almost always going to result in an HTTP 404 response.
  • Ask for the timestamp.json metadata. If this file hasn’t changed, there’s no need to ask for more metadata - nothing has changed.
  • Ask for the snapshot.json metadata. If this file hasn’t changed, there’s no need to ask for more metadata - the targets have not changed.
  • Ask for the targets.json metadata. At this point the device can see if a new Target is available for installation.