Skip to content

Latest commit

 

History

History
91 lines (59 loc) · 7.3 KB

client-provisioning-methods.adoc

File metadata and controls

91 lines (59 loc) · 7.3 KB
Raw

Device Provisioning Methods

Note

We recommend that you view this article in our documentation portal. Not all of our articles render correctly in GitHub.

What is device provisioning?

OTA Connect uses mutual TLS for transport security and device authentication. This means that:

  • every device needs to have its own X.509 certificate,

  • every device needs to have a way to trust the X.509 certificate of the OTA Connect server’s device gateway, and

  • the OTA Connect server needs to have a way to decide whether it trusts each vehicle’s X.509 certificate.

The vehicle knows it can trust the gateway because each OTA Connect account gets a unique device gateway URL, with its own unique X.509 certificate. We then include that certificate in the credentials.zip you download, and it gets baked into the image as a pinned certificate authority (CA) when you bitbake.

The device gateway decides whether to allow a device to connect based on the device’s X.509 certificate. Every OTA Connect account has one or more Fleet Root CAs which are responsible for signing device certificates. When a device connects, your device gateway checks whether its certificate is signed by a trusted Fleet Root CA, and if not, rejects the connection.

Device provisioning, therefore, is simply the process of providing a device with:

  • an X.509 certificate

    • that is unique to the vehicle

      • and is signed by a Fleet Root CA that your OTA Connect account trusts

How to provision devices

OTA Connect supports two provisioning methods: "provisioning with shared credentials" and "provisioning with device credentials". No matter which method you choose, you’ll end up in the same place: each of your devices will have its own signed certificate, and will use that certificate to identify itself and establish a secure communication channel with the server (via mutual TLS).

The difference between the two methods is in how exactly that certificate gets to the vehicle, and who controls the Fleet Root CA. Let’s take a closer look at how each method works.

Provisioning with shared credentials

This type of provisioning is the default, and is great to start with, because the OTA Connect server does everything for you: it generates a Fleet Root CA for your account, and it generates a new vehicle certificate every time a new device comes online. This allows you to try out OTA Connect without involving the rest of your infrastructure. However, this method may not be secure enough for a production scenario.

In shared credential provisioning, the OTA Connect server creates the Fleet Root CA for you, and stores the private key for the CA in a Vault instance. The server also generates a credential for you that can be shared amongst all the devices in your fleet. That credential—​also known as a provisioning key—​is included in your credentials.zip, and is baked into the generic image that you flash on all your devices.

In this method, the following steps occur:

  1. You download your credentials.zip with the provisioning key inside.

  2. You bitbake an image with the default provisioning method configured, providing bitbake with your credentials.zip.

  3. You flash that image on as many devices as you wish.

  4. The first time each device comes online, it connects to a special endpoint on the device gateway and says, “Hi, I’m a new device, and I don’t have a TLS certificate yet. Here’s my provisioning key.”

  5. Our crypto service generates a new keypair and X.509 certificate for the device, signs that certificate with the private Fleet Root CA in the Vault instance, and sends the whole bundle to the vehicle.

  6. The crypto service deletes the vehicle’s private key and the device stores its new keypair and certificate.

This entire transaction is secured with TLS, using the pinned device gateway certificate provisioned in the image.

img::shared cred provisioning
Figure 1. Summary of Shared credential provisioning

Provisioning with device credentials

We usually recommend this provisioning method if you have high cybersecurity compliance needs, and especially if you have devices with a hardware security module. In this method there is no shared credential. Instead, the following steps occur:

  1. You provide us with your own Fleet Root CA’s certificate (but NOT the private key).

  2. Then, you make sure that each device acquires, in some out-of-band process, an X.509 certificate signed by your Fleet Root CA.

    For maximum security, you would generate a keypair and a self-signed X.509 certificate inside an HSM on the device (so that there’s never any private key material outside of the HSM), then submit a PKCS#10 certificate signing request (CSR) to an appropriate service inside your own PKI, using an authentication method appropriate to your security needs. In an automotive OEM context, for example, that might be a private server inside the factory infrastructure, using the physical location and an airgapped network as ways to authenticate the CSR’s validity.

  3. Once the device has its signed certificate, it can already establish a mutual TLS connection with OTA Connect server. Any time a device that’s not already in the system connects with a valid certificate, we add it to your fleet, using the CNI on the vehicle certificate as the device ID.

Note that nowhere in this process have we had to use a shared credential, nor has any private key material existed outside of the vehicle (for vehicle keys), or your own PKI (for the Fleet Root CA). We have also used mutual TLS for transport security right from the beginning. This is why we describe this process as the more secure option.

Tip
 For a more practical overview, read our step-by-step guide to setting up device credential provisioning.
img::device cred provisioning
Figure 2. Summary of Device credential provisioning

Setting up the OTA Connect Server for Provisioning

If you want to use "shared credential" provisioning, you don’t have to do anything at all. When your account was created, we already generated a Fleet Root CA and keypair for you, and stored them on the OTA Connect server. We take the security of these keys extremely seriously: following industry best practices, they are kept in a Vault instance and only taken out when you request them.

If you want to use "device credential" provisioning, provide us with your Fleet Root CA so that the OTA Connect server can verify devices. Of course, you can use both methods, but in that case, we recommend that you maintain separate environments:

  • one for testing with "shared credential" provisioning

  • one for production with "device credential" provisioning

It is not possible to migrate from a test environment to a production environment. Therefore, we recommend that you test with devices that do not go into production or devices that can be completely wiped and reset once they are ready to deploy. Once you are ready for production, you should use your production environment, your own Fleet Root certificate, and production devices that have their device certificates preinstalled.