Traditionally, a centralized approach to rights management started at the certificate authority (CA). The CA certified that the manufacturer is known and trusted by the CA. The manufacture then certified that they built the device. The consumer sitting at the end of this chain is expected to trust the device because the root of trust started at the certificate authority. From this chain of trust, device access rights would be applied. This approach validates that the device is authentic and was indeed created by this manufacturer but does not establish ownership required to identify other devices allowed access.
While in some cases, users may want to verify that the device was truly built by the manufacturer. We argue that trust does not have to be managed by a central authority but is also useful if it starts at the consumer.
In this model, the consumer trusts the devices they have purchased, and thus rights can be applied to device they own. They can then extend trust to other devices. The consumer should also have the ability to extend trust to other parties, or completely sell the device to a new owner.
We quickly realized that access should not be managed at the device level, but more granular at the resource, while a device may include multiple resources (or resource groups). Further, there may be different owners for each resource. For example, a door lock may have two resources. One resource is the locking mechanism, which is owned and controlled by the consumer. The second is the firmware update resource, which may be owned by the device manufacturer.
IoT Trust Ledger
All of these relationships can be managed using a decentralized ledger. All transactions are cryptographically signed by the consumer, and validated through a consensus network. The consensus network prevents any single node from altering the ledger without approval from the network. The trust relationships are managed through a secured smart contract. The contract is executed on the distributed network, which reduces the risk of a Denial of Service attack. Most important, the network does not have a single point of failure and would continue to operate even if the membership changes.
Vtegrity from Verimatrix provides support for secure boot, secure update, certificate provisioning, and certificate lifecycle management. The identity of a device must be secured, prior to any rights management. Through the provisioning service, Vtegrity simplifies the deployment, management, and secure storage of device’s certificate. Further, Vtegrity is built on hardware enabled security, which not only provides key protection, but also ensures the integrity of the code running on the device. Click here for more information.
For more detailed information, please read our new paper.