Part 2. Device Security

Example Device Lifecycle

Overview
Lifecycle stages

The Example device has several stages in its lifecycle where different authorities have control over aspects of the device.

  • At manufacture of the device the Example licensing authority (NLA) provides credentials to the device that enable the device.
  • The end user uses these credentials to authorize the Example Licensing Authority to enable the device to be linked to the Example Account Service Provider.
  • The Example Account Service Provider is then able to download credentials to the device that allow the device to be controlled securely by a Example Service Provider or Apps that the end user allows to interact with their User Account.

device lifecycle

Manufacture of Device

During manufacture the device will have the following credentials inserted into the device:

  1. Unique ID.
  2. Unique Password.
  3. Private Key of the device.
  4. Root X.509 Certificate for the Example Licensing Authority.
  5. Master Issuer ID. This is the value of the "iss" field that must be present in a JSON Web Token. This is further outlined in the section describing JWT usage.
  6. X.509 Certificate for the Firmware Update Service. This key is unique per Device Manufacturer.
  7. X.509 Certificate and Private Key for the TLS communication security. This certificate is unique to the device.
  8. X.509 TLS Root Certificate(s). These are the root certificates that the device may use to validate a Web Service that the device is interacting with.

The above credentials, with the exception of the Certificate for the Firmware Update Service, are permanent for the entire life cycle of the device.

The Unique ID, Unique Password, Private Key, and X.509 certificates are issued by the Example Certificate Authority (CA).

The Unique ID and Password should be readily accessible to the device owner.

  • These should be either visible on the casing of the device or accessible through near field communication.
  • The private keys should be securely stored on the device.

The following JSON structure is provided by the Example LA to the device manufacturer using a secured channel to the manufacturer.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "title": "Device Security Package",
  "additionalProperties": false,
  "properties": {
    "Unique ID": {
      "type": "string",
      "description": "Permanent ID of the device. Readable by end user."
    },
    "Unique Password": {
      "type": "string",
      "description": "Password used to log into Example LA device account and associate device with Example Account Service Provider"
    },
    "Device Private Key": {
      "type": "string",
      "description": "Permanent Private Key of Device - Shall be securely handled"
    },
    "Root Certificate for Example LA": {
      "type": "string",
      "description": "X.509 Certificate for the Example LA"
    },
    "Master Issuer ID": {
      "type": "string",
      "description": "\"iss\" field in a JWT issed by the Example LA to allow another entitty to access the device"
    },
    "Code Signing Certificate": {
      "type": "string",
      "description": "X.509 Certificate containing verification key for firmware upgrades"
    },
    "TLS Root Certificates": {
      "type": "array",
      "items": [
        {
          "type": "string",
          "title": "TLS Root Certificate",
          "description": "Root Certificate used to validate X.509 certificate provided by server or client interacting with device."
        }
      ]
    },
    "TLS Configuration": {
      "type": "object",
      "properties": {
        "X.509 Certificate": {
          "type": "string",
          "description": "X.509 Certificate to be used for securing TLS communication."
        },
        "Private Key": {
          "type": "string"
        },
        "OCSP URL": {
          "type": "string",
          "title": "OCSP URL",
          "description": "Location of OCSP service"
        }
      }
    }
  }
}
Device Seller Registers Device with Example LA

The Device Seller is the brand or distributor who actually markets the product and manages any software updates in the field. The Example LA will only issue an X.509 certificate for a device and assign the device to a Example Account Service if the device has been registered with the Example LA by the Device Seller.

The following JSON object shall be provided by the Device Seller to the Example LA to register the device with the Example LA.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "title": "My schema",
  "additionalProperties": false,
  "properties": {
    "Manufacturer ID": {
      "type": "string"
    },
    "Model Type": {
      "type": "string"
    },
    "Seller ID": {
      "type": "string"
    },
    "Unique ID": {
      "type": "string"
    }
  }
}
User Associates Device with User Account

The end user can link devices to their account. It is envisioned that a consumer will have 10’s of devices associated with their account while an enterprise may have 1000’s of devices associated with their account.

  1. The end user accesses the Unique ID and Password that has been provided with the Device.
    1. There may be several methods used to deliver the password to the end user.
    2. These include having the Unique ID visible on the housing of the device or readable via NFC.
  2. The Unique ID and Password is used to access the account for the device that exists in the Example Licensing Authority and not to directly access the device itself.
  3. The end user logs-on to their Example Account Service Provider account and is redirected to the Example licensing authority which accepts the device credentials provider by the end user and provides an Access Token to the Example service provider.
    1. The Access Token enables the Example Account Service Provider to interact with the Device.

The Example LA will only allow the linkage of the Device to a Example Service Account and provide the device’s X.509 certificate if the Device Seller has already registered the device with the Example LA.

Example Account Service Configures Device

Once the device has been associated with a user’s account, the Example Account Service writes the following object into the device:

Example Account Service Security Object

The device is now ready to operate.

Linking Device to Different User Account

The end user may decide to use a different Example Account Service Provider, or may give away or sell the device to another party.

  • The end user must first delete the device from their account for it to be available for another user to link the device to their account.
  • The Example Account Server shall then communicate with the Example LA to indicate that the device is no longer associated with an End User Account, effectively putting the device back into the state where the device is unallocated to a user but still registered to the Example LA as having been shipped by a specific Device Seller.

▲ Top