Talking about security requires precision. However, precise language can be hard to digest for even most technical audiences. What follows is what I call a "pepperoni pizza" article. It's nobody's first choice, but most everyone can eat it.
Background
Every device in a factory communicates with Foundries.io via a device gateway. The device gateway connection is secured with mutual TLS. To make it easy to get started with a Factory, we maintain a device gateway, ota-lite.foundries.io:8443, with keys owned by Foundries.io.
You shouldn't want that, and we provide the ability for you to take ownership of the Public Key Infrastructure (PKI) for your Factory's device gateway and devices. Additionally, by owning the PKI, you can customize your manufacturing process to not require lmp-device-register and/or access api.foundries.io.
Taking ownership of this and TUF root keys gives you complete ownership of your TUF metadata and device gateway security.
Taking Ownership
tldr; Run fioctl keys ca create. This creates a PKI infrastructure that you own.
The remainder of this section describes the purpose of each certificate.
Factory root certificate
This keypair (factory_ca.key, factory_ca.pem) is the root of trust for all other keys. Once set, api.foundries.io requires other PKI related operations to prove ownership of this private key. Thus, it's critical to store this private key securely. The create command supports HSM/PKCS11 to help with this.
Server TLS Certificate
The device gateway needs a TLS keypair for encrypting communication between your devices and itself. Our backend creates a private key and returns a Certificate Signing Request (CSR) to fioctl during the fioctl keys ca create command. The CSR is signed with the root key and the resulting certificate is uploaded to Foundries.io. We can verify this certificate by asserting it has been signed with the factory root key.
With this key in place, devices can trust they have a secure connection to the device gateway.
Device Authentication Certificate
Mutual TLS requires clients (LmP devices) provide a client certificate that has been signed by a CA trusted by the server. fioctl keys ca create creates two CAs by default:
"online" - This is an intermediate CA owned by Foundries.io, signed with your root CA. This is required for lmp-device-register to work.
"local" - This is zero or more intermediate CA's owned by you, signed with your root CA. A local key can be used in your internal processes (e.g. manufacturing) for creating client certificates for devices without online access to
api.foundries.io.
These can be managed after initial creation with fioctl keys ca update.
How to use a "local" CA
Client certificates need to be created in a certain way for the server to process them correctly. Since each customer has unique manufacturing requirements, we built a minimal reference server that can be forked and extended. We call it the Factory Registration Reference server.
The API it exposes is compatible with lmp-device-register. This allows you to reuse existing tooling if you'd like.
There are lots of possibilities with this tool. For example, a customer might have their own internal API they want devices to access. They could extend this project to inform their backend API of these client certificates being created. Your devices could then talk to your own API server using mutual TLS.
Begin managing your Linux IoT devices with FoundriesFactory today!