Overview #
Faction pods are normal, off-the-shelf WiFi routers which are:
- wiped and then installed and pre-configured with Faction firmware;
- managed by the Faction Platform until ‘adopted’ by a Faction Network Owner into his/her network; and
- thereafter are no longer accessible or visible to the Faction Platform – which can thus not be a vector for attack or any information of use to attackers about Pods that have been adopted.
The Faction platform and process at all times protects and prevents the manipulation of the Factionized Pod from unauthorized third parties (presumed to be malicious) until it is adopted and managed by the Faction Network Owner which has purchased it.
The Faction Platform will maintain complete record of all activity and actions of a Pod throughout its lifetime in our universe. The minute the Network Owner adopts a pod, it leaves that universe. However, all of the records of the Pod up until that moment are maintained so that customer support inquires, returns & exchanges and so on can be handled.
The same firmware installation and process can be applied in principle to any other network routable device which can connect to a Faction Network.
Factionizing Pods #
The process of wiping and then installing and configuring an existing Pod with Faction firmware is called “Faction-izing” a Pod. This is currently done with scripts run by the command line, which will be replaced by a Web UI/UX which connects securely to the Faction PMP.
Onboarding Generic Pods #
Information for existing, off-the-shelf Pods which have been purchased by Faction Communications are input or uploaded into the PMP (e.g. Make, Model, OEM Serial number, date of arrival, related shipping information, etc.).
In order to be able to access the PMP for onboarding or flashing pods for use on the Faction network, you need to be pre-approved. This is a highly controlled step which is manual today and in the future will incorporate biometric and/or human-in-the-loop visual identify verification.
The Faction PMP assigns a unique internal identifier to each Pod – which acts in effect as our own Serial Number for the device. This will be used later to validate and confirm that a Pod a customer is adopting on our. network (customers can input or scan a barcode. This Faction Unique Identifier (FUI) is stored in the PMP and is used to associate with the one-time Pod Adoption Key keys assigned by the Faction PMP to any given Pod that is being Factionized.
Flashing and Configuration #
To start the process, Pods must:
- be physically connected (via Ethernet typically) to the Faction Pod Configuration Machine (PCM), which is on the Faction Network (and thus inaccessible to the Internet and can ONLY connect to the Faction PMP); and
- also have a connection to the internet, so that it can reach api.faction.live after programming.
The Factionizing process creates two public / private key pairs and related entries needed to enable the Adoption process.
- Faction Pod Programming Network Key used to provision the device onto the Faction Network that connects to the PMP
- The programming process creates a wireguard private key, from which a public key is extracted, on the api.faction.live server.
- A random, unique, IPv6 address for the pod-to-be-programmed is also created.
- Pod Adoption Key used to configure the device the enable it to be adopted by the Faction Network Owner/Administrator
- Another wireguard private key is created for the pod, and the public key copied to the api.faction.live server.
- A new entry is created in the wg02.conf file for the pod, and the tunnel restarted on api.faction.live. This permits the pod to connect to the pod adoption network.
Note well that the pod FUI does not get installed on the pod – it’s just a reference to the database entry, so the sticker with the QR code/FUI number is essential to be able to reference that pod in the future.
The pod is then restarted, and connectivity to its IPv6 address is validated (meaning that the pod successfully connects to the api.faction.live Wireguard server, and is able to route traffic).
This completes the pod programming.
Faction Pods Management #
Pods that have been Factionized continue to be managed in the PMP until they are purchased, shipped and then adopted by Faction Network owners. This part of the platform is primarily about the management of the Faction Pods inventory and all the information required to support their shipping and handling and any subsequent support, returns and exchange for customers.
Adoption of Faction Pods by Customers #
Note – from a UX standpoint all of the following happens automatically after the Network Owner has powered up and connected the Pod as per instructions.
When the device is powered up and successfully connected to a network, its first – and only – connection will be to the Faction Pod Programming Network (and then to the PMP). It is not possible for a Pod to connect to anything else, unless its firmware has been altered, and Faction is implementing multiple layers of both digital and physical world security to protect again supply chain attacks, and ensure that any alteration of Pod firmware is not possible without detection.
When the Network Owner uses the Faction App to ‘Adopt’ a Faction Pod, the following sequence of events are executed.
- The Pod connects via the Faction Pod Programming Network to the PMP, now it is assigned an ipv6 address and is visible.
- The network owner gets the FUI and enters it (either by scanning the barcode or manual entry). This allows api.faction.live to obtain the ssh key.
- The Faction server creates a new wireguard network key, and transmits the public portion to the network owner.
- The Faction server creates a new IPv6 address in the Network Owners’ faction, and transmits that to the network owner.
- The Network Owner creates a new wireguard private key, and transmits the public portion to the Faction Server. Now we have sufficient information to build the new Wireguard link for the new device (in this case, a pod).
- The IPv6 address, the private Wireguard key, and the Faction Server’s newly created public key are sent to api.faction.live
- api.faction.live can then connect to the pod using the retrieved ssh key, and install the new IPv6 address, the path to the Faction Server, and the private Wireguard key. The pod is then rebooted, removing it from the programming network, and moving it to the Network Owner’s faction network.
- The ssh private key is transmitted to the Network Owner.
- The network owner generates a new ssh private key, and the public portion of this is installed on the pod using the existing ssh key. This then removes any trace of the keys which were factory installed on the pod.
- The keys on the Faction API server for the wireguard link to the pod are removed and destroyed.
- The database entries on the Faction API server are destroyed, removing any trace of the keys which are no longer usable.