HERE OTA Connect is designed to integrate easily into development workflows: you build your image, push it, set auto-updates for some of your test-bench devices, and so on. But once you’re ready to move from testing into production, you will likely want to do a few things differently. Here is a summary of our recommended workflow for moving from development to production.
Maintain separate accounts for development, testing and production
There are (at least) two good reasons to separate your dev/testing accounts from production:
Isolation of production-ready deployments
OTA Connect does not support deleting devices or device images. We do this for auditability, but it does mean that your dev/testing account can end up getting a bit cluttered. You wouldn’t want to accidentally select the wrong build on a production run.
Separation of responsibilities
Chances are, your developer team isn’t responsible for making the decision to push updates live. You can cross-deploy images that are ready for testing to a test account controlled by QA, then once again to an account for production once they’ve passed QA.
To make this workflow possible, create an account for each environment you find useful (e.g. dev, QA, beta, production, etc.), and then read about using garage-deploy to cross-deploy images from one account to another.
Manage your own chain(s) of trust
When you create an account, and when you create provisioning credentials, we generate various keys for you. There’s a table here listing everything that’s in
credentials.zip, but the main thing you need to know is that there are two root authorities that we initially generate: a root CA for authenticating your devices during provisioning, and a private key for signing the metadata of the images you build. We take the security of these keys/certificates extremely seriously: following industry best practices, they are kept in a Vault instance and only taken out when you request them.
However, we don’t need to have the keys at all. You can manage your own root CAs in both cases. Images you build get signed locally before being pushed, and OTA Connect only needs to verify the signatures, and thus doesn’t need to keep your private key on hand. And if you prefer to manage your own fleet provisioning key, you can provide us with your public key, and then use implicit provisioning for your devices.
Once you’ve done that, we won’t have any of your private key material at all.
Consider using a Hardware Security Module
In the quickstart guides, we automatically provision your devices when they come online for the first time. To make this happen, the devices need to present a provisioning key. If the provisioning key is valid, then OTA Connect bootstraps the provisioning process by negotiating unique, device-specific credentials in the form of X.509 certificates for mutual TLS authentication. It’s these generated credentials that are used when the device connects to the server for updates. The provisioning key is only used once, on first boot.
HERE OTA Connect also supports another type of provisioning; we refer to it as implicit provisioning. In this case, the device is pre-loaded with the requisite bootstrap credentials, signed by a root CA of your choice. These can be stored in the HSM, obviating the need for a provisioning key on the device that could potentially be compromised, and also obviating the need for us to hold key material for provisioning.
How the HSM for your individual board or device works is up to you, but you can simulate a hardware security module in QEMU to get an idea of how the process works. We provide instructions for QEMU HSM provisioning only; if you need development support in adapting the instructions to your own board, contact us for a consultation.